From guest  Fri May  1 03:00:34 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id CAA03448 for info-performer-dist@holodeck.engr.sgi.com; Fri, 1 May 1998 02:44: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 CAA03421 for <info-performer@holodeck.engr.sgi.com>; Fri, 1 May 1998 02:44: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 CAA6861007
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 1 May 1998 02:44:57 -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 CAA15036
	for <info-performer@sgi.com>; Fri, 1 May 1998 02:44:55 -0700 (PDT)
	mail_from (Ruddle@cardiff.ac.uk)
Received: from thor.cf.ac.uk by crane.cf.ac.uk with SMTP-LOC (PP);
          Fri, 1 May 1998 10:40:35 +0100
Received: from localhost (saprar@localhost) by thor.cf.ac.uk (8.8.8/8.6.12) 
          with SMTP id KAA05935 for <info-performer@sgi.com>;
          Fri, 1 May 1998 10:44:24 +0100 (BST)
Date: Fri, 1 May 1998 10:44:23 +0100 (BST)
From: Roy Ruddle <Ruddle@cardiff.ac.uk>
Reply-To: Ruddle@cardiff.ac.uk
To: info-performer@sgi.com
Subject: Re: Variable chan updates (fixed)
In-Reply-To: <9804301028.ZM1017@atlantis>
Message-ID: <Pine.OSF.3.95q.980501104229.5724A-100000@thor>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

> pfPipe::setSwapFunc( pfPipe* p, pfPipeWindow* pw);
> pfPipeWindow::swapBuffers();
> 
Perfect. Does exactly what I want. Thanks Jean-Luc

cheers

roy

=======================================================================
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 May  1 09:27:28 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA04313 for info-performer-dist@holodeck.engr.sgi.com; Fri, 1 May 1998 09:14: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 JAA04286 for <info-performer@holodeck.engr.sgi.com>; Fri, 1 May 1998 09:14: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 JAA16549532
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 1 May 1998 09:14:38 -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 JAA16367
	for <info-performer@sgi.com>; Fri, 1 May 1998 09:14:36 -0700 (PDT)
	mail_from (slevy@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 LAA21918
	for <info-performer@sgi.com>; Fri, 1 May 1998 11:14:36 -0500 (CDT)
Received: from impact13.ncsa.uiuc.edu (impact13.ncsa.uiuc.edu [141.142.220.23])
	by mx1.ncsa.uiuc.edu (8.8.8/8.8.8) with ESMTP id LAA10124
	for <info-performer@sgi.com>; Fri, 1 May 1998 11:14:35 -0500 (CDT)
From: Stuart Levy <slevy@ncsa.uiuc.edu>
Received: (from slevy@localhost)
	by impact13.ncsa.uiuc.edu (8.8.5/8.8.5) id LAA05725
	for info-performer@sgi.com; Fri, 1 May 1998 11:14:35 -0500 (CDT)
Date: Fri, 1 May 1998 11:14:35 -0500 (CDT)
Message-Id: <199805011614.LAA05725@impact13.ncsa.uiuc.edu>
To: info-performer@sgi.com
Subject: Performer 2.2 "compat" libraries ineffective?
Status: O

As Bill Sherman has been explaining recently, we've been having
a good deal of trouble with applications which worked under Performer 2.0
and 2.1 and now misbehave when run in a Performer 2.2 environment,
even though the Perf 2.2 "compatibility" packages have been installed.

We've been trying to localize the problems well enough that SGI can
try to solve them.  The summary below is my current understanding of
what's broken.

(1) Some apps compiled & linked in a Performer 2.0/2.1 environment refuse to
    find (for example) iv and iv20 loaders, even though the corresponding
    libpfiv_ogl.so and libpfiv20_ogl.so libraries exist and are successfully
    opened by the app, according to par(1).

    They consistently attempt to find Performer loaders by mapping
    the unqualified library names (libXXX.so, which are sym-links to the
    libXXX.so.4 latest Performer libs) rather than using names
    qualified by the major version number (libXXX.so.2) with which the
    program was originally linked.

    So if the installed version of Performer is different from the one
    they were linked with, the library versions fail to match, and the
    Performer loaders aren't found even though the correct versions do
    exist in /usr/lib/libpfdb.

    Putting appropriately-sym-linked .so files into {PF,}LD_LIBRARY_PATH
    allows them to find the relevant loaders.

    See
	http://www.ncsa.uiuc.edu/~slevy/perfbugs
    for details, including system-call traces and PFNFYLEVEL=9
    debugging output.

    [By the way, some existing binaries *do* seem to search for Performer
     libraries by their .so.N qualified name.  What causes the difference?]

(2) Still, these apps lose material properties (color and transparency)
    on objects they display, i.e., simple colored objects are rendered
    as opaque gray (probably actually white).

    Textured objects are textured pretty much as expected, although 
    the textures appear opaque (so e.g. billboarded trees become opaque
    rectangles with trees pasted on them!).

    Lighting looks reasonable and may be correct, though it's just the
    environment's lighting; the objs we load don't include their own lights.

    The incompatibility appears to lie somewhere in the compat-mode
    /usr/lib/libpf_ogl.so.{2,3} libraries as distributed with Performer 2.2.
    If we just *replace* these with /usr/lib/libpf_ogl.so.{2,3}
    as copied from a system with Performer 2.{0,1} installed,
    that's sufficient to make material properties behave normally again.
    [They needn't be replaced in situ in /usr/lib; it's enough to put the
     appropriate libpf_ogl.so somewhere and point LD_LIBRARY_PATH at it.]

(3) After recompiling a Performer 2.{0,1} app which reads VRML 1.0 files
    on a Performer 2.2 system, it can no longer read them; Performer 2.2's
    .wrl reader accepts only VRML 2, not VRML 1 files.

    The new wrl loader is nice enough to explain the problem and suggest
    a VRML 1->2 converter, but we don't want to use that on all the
    app's data files -- we'd like to have an app that can run in
    *either* a Performer 2.{0,1} *or* 2.2 environment, and Performer
    2.{0,1} can't read VRML 2 files.

    [Workaround: add pfAddExtAlias("wrl", "iv"); pfdInitConverter("iv");
     to these programs.  But can we do better?]

Does anyone else see symptoms like these?

  Stuart Levy, slevy@ncsa.uiuc.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 May  1 11:23:37 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA04625 for info-performer-dist@holodeck.engr.sgi.com; Fri, 1 May 1998 11:04: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 LAA04598 for <info-performer@holodeck.engr.sgi.com>; Fri, 1 May 1998 11:04: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 LAA17008753
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 1 May 1998 11:04:57 -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 LAA01288
	for <info-performer@sgi.com>; Fri, 1 May 1998 11:04:52 -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 NAA28084 for <info-performer@sgi.com>; Fri, 1 May 1998 13:04:48 -0500 (CDT)
Date: Fri, 1 May 1998 13:03:34 -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: pfUpdatable::pf_addUpdate ??!
Message-ID: <Pine.SGI.3.96.980501125859.1088A-100000@sutcliffe.bgm.link.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O



I'm seeing this message coming out of Perf2.2 MR, can anyone
translate it into English for me?

DEBUG pfUpdatable::pf_addUpdate not called from APP process=PID:16364 DBASE ,Updatable=pfGroup

...sometimes it says 'pfLOD' instead of 'pfGroup'.

What is the function of this 'pf_addUpdate' function - and what might I be 
calling that in turn is calling it?

I am paging data from disk in my DBASE process - and every now and again I'll
get zillions of these messages.

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 May  1 12:09:52 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA04754 for info-performer-dist@holodeck.engr.sgi.com; Fri, 1 May 1998 11:53: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 LAA04727 for <info-performer@holodeck.engr.sgi.com>; Fri, 1 May 1998 11:53: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 LAA18740530
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 1 May 1998 11:53:34 -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 LAA20747
	for <info-performer@sgi.com>; Fri, 1 May 1998 11:53:32 -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 MAA19889 for <info-performer@sgi.com>; Fri, 1 May 1998 12:04: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 SAA29904 for <@plateau.engr.multigen.com:info-performer@sgi.com>; Fri, 1 May 1998 18:54:39 GMT
Received: (from marcus@localhost) by logan.engr.multigen.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA02300 for info-performer@sgi.com; Fri, 1 May 1998 11:54:38 -0700
From: "Marcus Barnes" <marcus@multigen.com>
Message-Id: <9805011154.ZM2298@logan.engr.multigen.com>
Date: Fri, 1 May 1998 11:54:38 -0700
In-Reply-To: Stuart Levy <slevy@ncsa.uiuc.edu>
        "Performer 2.2 "compat" libraries ineffective?" (May  1, 11:14am)
References: <199805011614.LAA05725@impact13.ncsa.uiuc.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: Performer 2.2 "compat" libraries ineffective?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On May 1, 11:14am, Stuart Levy wrote:
>(1) Some apps compiled & linked in a Performer 2.0/2.1 environment refuse to
>    find (for example) iv and iv20 loaders, even though the corresponding
>    libpfiv_ogl.so and libpfiv20_ogl.so libraries exist and are successfully
>    opened by the app, according to par(1).
>
>    They consistently attempt to find Performer loaders by mapping
>    the unqualified library names (libXXX.so, which are sym-links to the
>    libXXX.so.4 latest Performer libs) rather than using names
>    qualified by the major version number (libXXX.so.2) with which the
>    program was originally linked.
>
>    So if the installed version of Performer is different from the one
>    they were linked with, the library versions fail to match, and the
>    Performer loaders aren't found even though the correct versions do
>    exist in /usr/lib/libpfdb.
>
>    Putting appropriately-sym-linked .so files into {PF,}LD_LIBRARY_PATH
>    allows them to find the relevant loaders.
>
>    [By the way, some existing binaries *do* seem to search for Performer
>     libraries by their .so.N qualified name.  What causes the difference?]

The newer rld is the problem. You get it with IRIX 6.4 and if you have
installed patch 2458. Replacement patch 2715 resolves the problem on my IRIX
6.3 system. SGI can cross reference CASE ID# 0914635.

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  Fri May  1 13:56:11 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA05061 for info-performer-dist@holodeck.engr.sgi.com; Fri, 1 May 1998 13:43: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 NAA05034 for <info-performer@holodeck.engr.sgi.com>; Fri, 1 May 1998 13:43: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 NAA19111506
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 1 May 1998 13:43:17 -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 NAA02017
	for <info-performer@sgi.com>; Fri, 1 May 1998 13:43:15 -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 QAA13332
	for <info-performer@sgi.com>; Fri, 1 May 1998 16:43:14 -0400 (EDT)
Date: Fri, 1 May 1998 16:43:14 -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.980501164145.15452K-100000@gold-cl.cmf.nrl.navy.mil>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O


Hello pfers:  

Well maybe the question is too trivial, but here it is again.

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  Fri May  1 14:11:13 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA05106 for info-performer-dist@holodeck.engr.sgi.com; Fri, 1 May 1998 13:53: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 NAA05079 for <info-performer@holodeck.engr.sgi.com>; Fri, 1 May 1998 13:53: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 NAA18675559
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 1 May 1998 13:53:42 -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 NAA05987
	for <info-performer@sgi.com>; Fri, 1 May 1998 13:53:41 -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 PAA06014;
	Fri, 1 May 1998 15:53:40 -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 PAA03073;
	Fri, 1 May 1998 15:53:39 -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 PAA11097; Fri, 1 May 1998 15:54:53 -0500 (CDT)
Date: Fri, 1 May 1998 15:54:53 -0500 (CDT)
Message-Id: <199805012054.PAA11097@space.ncsa.uiuc.edu>
To: info-performer@sgi.com, marcus@multigen.com, slevy@ncsa.uiuc.edu
Subject: Re: Performer 2.2 "compat" libraries ineffective?
Cc: wsherman@ncsa.uiuc.edu
Status: O

> On May 1, 11:14am, Stuart Levy wrote:
> >(1) Some apps compiled & linked in a Performer 2.0/2.1 environment refuse to
> >    find (for example) iv and iv20 loaders, even though the corresponding
> >    libpfiv_ogl.so and libpfiv20_ogl.so libraries exist and are successfully
> >    opened by the app, according to par(1).

And by the way, odd behaviour was exhibited by more than one application,
some of which hadn't been compiled in a year or so.  And a few of which
we were given only the executable, so recompiling is not even an option.

 
> The newer rld is the problem. You get it with IRIX 6.4 and if you have
> installed patch 2458. Replacement patch 2715 resolves the problem on my IRIX
> 6.3 system. SGI can cross reference CASE ID# 0914635.

Thanks for the info Marcus, it seems to be the best answer I've
seen so far, but ...

What happens if you're running 6.2, as in our case?

> Regards.
> --
> + Marcus Barnes, Technical Staff        mailto:marcus@multigen.com +

	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  Fri May  1 14:47:06 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA05368 for info-performer-dist@holodeck.engr.sgi.com; Fri, 1 May 1998 14:34: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 OAA05341 for <info-performer@holodeck.engr.sgi.com>; Fri, 1 May 1998 14:34: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 OAA19212866
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 1 May 1998 14:34:06 -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 OAA21570
	for <info-performer@sgi.com>; Fri, 1 May 1998 14:34:01 -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 OAA21016 for <info-performer@sgi.com>; Fri, 1 May 1998 14:44:59 -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 VAA04596 for <@plateau.engr.multigen.com:info-performer@sgi.com>; Fri, 1 May 1998 21:35:07 GMT
Received: (from marcus@localhost) by logan.engr.multigen.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA03730 for info-performer@sgi.com; Fri, 1 May 1998 14:35:06 -0700
From: "Marcus Barnes" <marcus@multigen.com>
Message-Id: <9805011435.ZM3728@logan.engr.multigen.com>
Date: Fri, 1 May 1998 14:35:06 -0700
In-Reply-To: Eddy Kuo <ekuo@ait.nrl.navy.mil>
        "More GeoSet Question" (Apr 30, 11:09am)
References: <Pine.SGI.3.91.980430110536.15452F-100000@gold-cl.cmf.nrl.navy.mil>
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: More GeoSet Question
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On Apr 30, 11:09am, Eddy Kuo wrote:
>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)

Maybe you are running on an iR machine? and you are using display lists? Make
sure you are drawing the fluxed geosets in immediate mode. See the pfGeoSet man
page wrt  PFGS_COMPILE_GL. If you are using perfly then use this command line
option "-T0" to see if this is the problem.

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  Fri May  1 14:47:09 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA05430 for info-performer-dist@holodeck.engr.sgi.com; Fri, 1 May 1998 14:38:28 -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 OAA05403 for <info-performer@holodeck.engr.sgi.com>; Fri, 1 May 1998 14:38: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 OAA18820380
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 1 May 1998 14:38:27 -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 OAA23225
	for <info-performer@sgi.com>; Fri, 1 May 1998 14:38:25 -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 RAA13653
	for <info-performer@sgi.com>; Fri, 1 May 1998 17:38:24 -0400 (EDT)
Date: Fri, 1 May 1998 17:38:24 -0400 (EDT)
From: Eddy Kuo <ekuo@ait.nrl.navy.mil>
To: info-performer@sgi.com
Subject: clearify the geoset question
Message-ID: <Pine.SGI.3.91.980501173045.24605B-100000@fargo.ait.nrl.navy.mil>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

Hello:

I am trying to display a changing geoset into four channels
each with different view.  I did use a geode to wrap around
the geoset.

I put a channel->clear() in my draw callback (otherwise, 
old geometry will no get erase)
The result is the image keep flashing as if I didn't have
any double buffering.  This flashing appear even when I
take out the channel->clear in the draw callback.

appreciate 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  Fri May  1 14:47:09 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA05477 for info-performer-dist@holodeck.engr.sgi.com; Fri, 1 May 1998 14:41: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 OAA05450 for <info-performer@holodeck.engr.sgi.com>; Fri, 1 May 1998 14:41: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 OAA19199957
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 1 May 1998 14:41:22 -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 OAA24318
	for <info-performer@sgi.com>; Fri, 1 May 1998 14:41:20 -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 OAA21082 for <info-performer@sgi.com>; Fri, 1 May 1998 14:52:18 -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 VAA04763 for <@plateau.engr.multigen.com:info-performer@sgi.com>; Fri, 1 May 1998 21:42:26 GMT
Received: (from marcus@localhost) by logan.engr.multigen.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA03798 for info-performer@sgi.com; Fri, 1 May 1998 14:42:25 -0700
From: "Marcus Barnes" <marcus@multigen.com>
Message-Id: <9805011442.ZM3796@logan.engr.multigen.com>
Date: Fri, 1 May 1998 14:42:25 -0700
In-Reply-To: William Sherman -Visualization <wsherman@ncsa.uiuc.edu>
        "Re: Performer 2.2 "compat" libraries ineffective?" (May  1,  3:54pm)
References: <199805012054.PAA11097@space.ncsa.uiuc.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: Performer 2.2 "compat" libraries ineffective?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On May 1,  3:54pm, William Sherman -Visualization wrote:
>marcus wrote:
>> The newer rld is the problem. You get it with IRIX 6.4 and if you have
>> installed patch 2458. Replacement patch 2715 resolves the problem on my IRIX
>> 6.3 system. SGI can cross reference CASE ID# 0914635.
>
>Thanks for the info Marcus, it seems to be the best answer I've
>seen so far, but ...
>
>What happens if you're running 6.2, as in our case?

You can either uninstall patch 2458 (or one of it's predecessors) or upgrade to
patch 2715 (or 3054). Here's the short of it:


Patch 3054: rld rollup #11 for 6.2, 6.3 and 6.4

SCR # 290198, 337982, 352206, 361758, 364118, 366990, 383655, 387407, 412725,
428927, 433288, 449282, 482870, 483964, 503926, 506076, 506166, 507206, 520846,
523673, 527001, 530749, 534245, 536186, 538535, 546958, 549580, 554894, 555509,
556199, 560586, 561583, 564479, 565027, 566180, 575110, 578951, 586353

Note: this patch replaces patch(es) 1266, 1270, 1336, 1384, 1584, 1681, 1932,
2044, 2261, 2458, 2715.

Description

       This patch contains fixes for the following bugs	in IRIX
       6.2, IRIX 6.3 and IRIX 6.4.  Bug	numbers	from Silicon
       Graphics	bug tracking system are	included for reference.

	  o Sgidlopen_version failed to	return handles for
	    versioned DSOs when	version	lookup required	searching
	    for	DSOs whose filenames had been suffixed with the
	    major version number (e.g.,	libfoo.so.2)  This was a
	    regression from the	rld in the 7.1 compiler	release
	    (Bug #560586).


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 May  2 03:23:55 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id DAA06880 for info-performer-dist@holodeck.engr.sgi.com; Sat, 2 May 1998 03:03: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 DAA06852 for <info-performer@holodeck.engr.sgi.com>; Sat, 2 May 1998 03:03: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 DAA18786338
	for <info-performer@cthulhu.engr.sgi.com>;
	Sat, 2 May 1998 03:03:05 -0700 (PDT)
Received: from 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 DAA27870
	for <info-performer@sgi.com>; Sat, 2 May 1998 03:02:59 -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 SAA28745 for <info-performer@sgi.com>; Sat, 2 May 1998 18:02:27 +0800 (SGT)
Received: from liuxy.nsrc.nus.sg(137.132.15.179) by aba.nsrc.nus.sg via smap (V1.3)
	id sma028736; Sat May  2 18:02:23 1998
Message-ID: <354AEF59.11BE@nsrc.nus.edu.sg>
Date: Sat, 02 May 1998 18:03:05 +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: uncalled pre-isect callback
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 7bit
Status: O

Hi, all.

I want to do bounding box to bounding box collision detection. 

My approach is by using a dummy vector to activate the ISECT
process, which in turn will activate the pre-isect callback
attached to each node. In this callback, "pfBox.contains ..."
is called to detect the collison between boxes.

What I found strange is that sometimes the pre-isect functions
is called , sometimes not, though the "printf" before the 
isect do print sth out. 

*****************************************************
The code looks like:

group->setTravFuncs(PFTRAV_ISECT, box2boxHit, NULL);
group->setTravData(PFTRAV_ISECT, (void *)shared_ptr);

int box2boxHit(pfTraverser *trav, void *data)
{  
  pfNode *node = trav->getNode();
  .... 
  if (box1.contains(&box2) != PFIS_FALSE) 
          printf("\n *************************MAY HIT");

  return PFTRAV_CONT;
}

 
 // collision detection between objects, use a dummy line
 // to initiate ISEC traversal, actual detection done in
 // each node's isecCallback.
 
          pfSegSet segset;
           pfHit **hits[32];
           segset.mode = PFTRAV_IS_GSET;
           segset.userData     = (void *)NULL;
           segset.activeMask   = 1;
           segset.isectMask    = 0xffffffff;      
           segset.bound        = (void *)NULL;
           segset.discFunc     = NULL;
           segset.segs[0].dir.set(0.0f, 0.0f, -1.0f); // dummy vector
           segset.segs[0].length = 1.0f;
           (shared_ptr->scene)->isect(&segset, hits);  // activate it
           
What's going wrong?

Thanks for any advice.

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  Sat May  2 13:18:55 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA07826 for info-performer-dist@holodeck.engr.sgi.com; Sat, 2 May 1998 13:08: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 NAA07799 for <info-performer@holodeck.engr.sgi.com>; Sat, 2 May 1998 13:08: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 NAA19543121
	for <info-performer@cthulhu.engr.sgi.com>;
	Sat, 2 May 1998 13:08:09 -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 NAA23352
	for <info-performer@sgi.com>; Sat, 2 May 1998 13:08:08 -0700 (PDT)
	mail_from (WRVO@chevron.com)
Received: (from uucp@localhost)
	by portalcp.chevron.com (8.8.8/8.8.8) id NAA04513;
	Sat, 2 May 1998 13:08:01 -0700 (PDT)
Received: from unknown(146.27.64.202) by portalcp.chevron.com via smap (4.0a)
	id xma004439; Sat, 2 May 98 13:07:40 -0700
Received: from chvpk-msx04-b.sr.chevron.com (chvpk-msx04-b.sr.chevron.com [146.27.94.42])
	by schizoid.sr.chevron.com (8.8.7/8.8.5) with ESMTP id NAA21830;
	Sat, 2 May 1998 13:07:40 -0700 (PDT)
Message-Id: <199805022007.NAA21830@schizoid.sr.chevron.com>
Received: by chvpk-msx04-b.sr.chevron.com with Internet Mail Service (5.0.1460.8)
	id <KDFPANC8>; Sat, 2 May 1998 13:07:40 -0700
From: "Volz, Bill (wrvo)" <WRVO@chevron.com>
To: "'Eddy Kuo'" <ekuo@ait.nrl.navy.mil>, info-performer@sgi.com
Subject: RE: clarify the geoset question
Date: Sat, 2 May 1998 13:07:37 -0700 
X-Mailer: Internet Mail Service (5.0.1460.8)
Status: O

I had a problem similar to this. I too was updating the geoset in one geode.
But it would only appear when another geode was added to the group. When
that second geode was removed, so did the contents of the first geode. It
was flashing too.

Here are two things that I found was happening:
1) the second geode contained a small cube that was placed on the screen at
the position of the cursor after an isect. I forgot to set the isect mask,
which defaults to 0xffffffff which means it isect with everything. When it
was not drawn, it isected with what it was supposed to and drew the cube.
Then it isected with the cube, but it wasn't the right things, so it removed
the small cube. Result was flashing of the geometry every other frame.

2) the changed geometry was not being drawn because I did not update the
bounding box and in particular the isect cache info. You need to call
setBound and also to reset the cache. I didn't have luck turning off the
cache and you probably don't want to. I did a curmask =
getIsectMask(PFTRAV_ISECT) followed by a
setIsectMask(PFTRAV_ISECT,curmask,....). Now the geometry is drawn and it
doesn't flash.
Hopes this helps.

Bill Volz


> -----Original Message-----
> From:	Eddy Kuo [SMTP:ekuo@ait.nrl.navy.mil]
> Sent:	Friday, May 01, 1998 4:38 PM
> To:	info-performer@sgi.com
> Subject:	clearify the geoset question
> 
> Hello:
> 
> I am trying to display a changing geoset into four channels
> each with different view.  I did use a geode to wrap around
> the geoset.
> 
> I put a channel->clear() in my draw callback (otherwise, 
> old geometry will no get erase)
> The result is the image keep flashing as if I didn't have
> any double buffering.  This flashing appear even when I
> take out the channel->clear in the draw callback.
> 
> appreciate 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
=======================================================================
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 May  2 19:23:53 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id TAA08361 for info-performer-dist@holodeck.engr.sgi.com; Sat, 2 May 1998 19:10: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 TAA08334 for <info-performer@holodeck.engr.sgi.com>; Sat, 2 May 1998 19:10: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 TAA19549426
	for <info-performer@cthulhu.engr.sgi.com>;
	Sat, 2 May 1998 19:10:15 -0700 (PDT)
Received: from acusoft.com (acusoft.acusoft.com [205.187.235.130]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id TAA14327
	for <info-performer@sgi.com>; Sat, 2 May 1998 19:10:14 -0700 (PDT)
	mail_from (miller@acusoft.com)
Received: from bats by acusoft.com (5.x/SMI-SVR4)
	id AA03996; Sat, 2 May 1998 22:10:12 -0400
Received: by bats (950413.SGI.8.6.12) id WAA19236; Sat, 2 May 1998 22:10:12 -0400
Date: Sat, 2 May 1998 22:10:12 -0400 (EDT)
From: "Thomas M. Miller" <miller@acusoft.com>
X-Sender: miller@bats
To: info-performer@sgi.com
Cc: Jesse Liu <liu@acusoft.com>, Wentao Lyou <lyou@acusoft.com>
Subject: 2 Pipe Hangup
Message-Id: <Pine.SGI.3.91.980502215323.19209E-100000@bats>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O



I am having a problem getting perfly to run on a 2 pipe Onyx 2 under IRIX 6.4
It runs fine if I limit the multipipe to 1 pipe.  Otherwise it runs until it
gets to a point where it should open the pfPipeWindows and then it hangs. It
dosn't seg fault or die it just hangs. I am pretty sure I got all the patches.
What am I missing?  Is genlocking required? 

also if I try to run a sample program such as morph_LOD on pipe 1 it will hang.

I tried the command: ( setenv DISPLAY :0.1 ; morph_LOD ) 

It opens a window on pipe 1 and then hangs. It never draws or exits.

Also, are the Archives still kept at ftp://sgigate.sgi.com/pub/Performer/ ?

--TMIV

=======================================================================
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 May  3 11:24:54 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA09665 for info-performer-dist@holodeck.engr.sgi.com; Sun, 3 May 1998 11:13: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 LAA09638 for <info-performer@holodeck.engr.sgi.com>; Sun, 3 May 1998 11:13: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 LAA19442062
	for <info-performer@cthulhu.engr.sgi.com>;
	Sun, 3 May 1998 11:13:50 -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 LAA27913
	for <info-performer@sgi.com>; Sun, 3 May 1998 11:13:49 -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 LAA01800; Sun, 3 May 1998 11:13:47 -0700
Date: Sun, 3 May 1998 11:13:47 -0700
From: src@rose.engr.sgi.com (Sharon Clay)
Message-Id: <9805031113.ZM1798@rose.engr.sgi.com>
In-Reply-To: "Thomas M. Miller" <miller@acusoft.com>
        "2 Pipe Hangup" (May  2, 10:10pm)
References: <Pine.SGI.3.91.980502215323.19209E-100000@bats>
X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail)
To: "Thomas M. Miller" <miller@acusoft.com>, info-performer@sgi.com
Subject: Re: 2 Pipe Hangup
Cc: Jesse Liu <liu@acusoft.com>, Wentao Lyou <lyou@acusoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

+>---- On May 2, 10:10pm, Thomas M. Miller wrote:
> Subject: 2 Pipe Hangup
->From guest@holodeck  Sat May  2 19:24:14 1998
->
->I am having a problem getting perfly to run on a 2 pipe Onyx 2 under IRIX 6.4
->It runs fine if I limit the multipipe to 1 pipe.  Otherwise it runs until it
->gets to a point where it should open the pfPipeWindows and then it hangs. It
->dosn't seg fault or die it just hangs. I am pretty sure I got all the patches.
->What am I missing?  Is genlocking required? 
->
->also if I try to run a sample program such as morph_LOD on pipe 1 it will hang.
->
->I tried the command: ( setenv DISPLAY :0.1 ; morph_LOD ) 
->

This sounds like you have patch1927 on your machine.  That was an
iR/X/GL patch that had an X bug that would cause all Performer windows
that were not on pipe 0 to hang.  Performer 2.2 had a WAR in it for this
and iR patch 2789 will replace patch1927 and fix it.

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  Sun May  3 12:43:24 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA09894 for info-performer-dist@holodeck.engr.sgi.com; Sun, 3 May 1998 12:24: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 MAA09867 for <info-performer@holodeck.engr.sgi.com>; Sun, 3 May 1998 12:24: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 MAA19773010
	for <info-performer@cthulhu.engr.sgi.com>;
	Sun, 3 May 1998 12:24:55 -0700 (PDT)
Received: from mailout05.btx.dtag.de (mailout05.btx.dtag.de [194.25.2.153]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id MAA08479; Sun, 3 May 1998 12:23:55 -0700 (PDT)
	mail_from (EWolpert@t-online.de)
Received: from fwd10.btx.dtag.de (fwd10.btx.dtag.de [194.25.2.170])
	by mailout05.btx.dtag.de with smtp 
	id 0yW4JX-0000H4-00; Sun, 3 May 1998 21:20:43 +0200
Received: from erwolper.erols.com (02635920161-0001(btxid)@[193.158.187.126]) 
	by fwd10.btx.dtag.de with smtp
	id <m0yW4Hh-0003QTx>; Sun, 3 May 1998 21:18:49 +0200
Message-ID: <354D09C4.1ACCAC6@t-online.de>
Date: Sun, 03 May 1998 21:20:20 -0300
X-Mailer: Mozilla 4.01 [de]C-DT  (Win95; I)
MIME-Version: 1.0
To: info-iris-admin@brl.mil
CC: info-iris-announce@brl.mil, info-iris-apps@brl.mil, info-iris-bugs@brl.mil,
        info-iris-graphics@brl.mil, info-iris-hardware@brl.mil,
        info-iris-misc@brl.mil, info-iris-request@brl.mil,
        explorer@holyrood.ed.ac.uk, sgilarge@uwindsor.ca,
        sgivar-l@psuvm.psu.edu, indigo-home@world.std.com, devedge@sgi.com,
        info-performer@sgi.com, security-alert@sgi.com, techpubs@sgi.com,
        sgi@pcinews.com, ilug@sgi.com, iris-on-line@sgigate.sgi.com,
        flexfax@sgi.com
Subject: SGI O2 WebFORCE + 172-Monitor, ALMOST NEW!
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Sender: 02635920161-0001@t-online.de
From: EWolpert@t-online.de (Erwin Wolpert)
Status: O

Hello,

might there be anybody interested in an O2-WebFORCE
(1 year old, little use)?
MIPS R5000 PC, 180MHz, 64MB RAM, 4GB HD + 17" Trinitron Monitor.
complete with Software in English.
I live in Germany near the Cities Koblenz/Bonn.
Price: DM 7.500,-
Phone: 02635/920161
eMail: ewolpert@t-online.de

Best regards
Erwin Wolpert

=======================================================================
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 May  3 14:41:59 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA10150 for info-performer-dist@holodeck.engr.sgi.com; Sun, 3 May 1998 14:23: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 OAA10123 for <info-performer@holodeck.engr.sgi.com>; Sun, 3 May 1998 14:23: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 OAA19721996
	for <info-performer@cthulhu.engr.sgi.com>;
	Sun, 3 May 1998 14:23:47 -0700 (PDT)
Received: from acusoft.com (acusoft.acusoft.com [205.187.235.130]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id OAA25594
	for <info-performer@sgi.com>; Sun, 3 May 1998 14:23:46 -0700 (PDT)
	mail_from (miller@acusoft.com)
Received: from bats by acusoft.com (5.x/SMI-SVR4)
	id AA04783; Sun, 3 May 1998 17:23:45 -0400
Received: by bats (950413.SGI.8.6.12) id RAA20675; Sun, 3 May 1998 17:23:44 -0400
Date: Sun, 3 May 1998 17:23:43 -0400 (EDT)
From: "Thomas M. Miller" <miller@acusoft.com>
X-Sender: miller@bats
To: Sharon Clay <src@rose.engr.sgi.com>
Cc: info-performer@sgi.com, Jesse Liu <liu@acusoft.com>,
        Wentao Lyou <lyou@acusoft.com>
Subject: Re: 2 Pipe Hangup
In-Reply-To: <9805031113.ZM1798@rose.engr.sgi.com>
Message-Id: <Pine.SGI.3.91.980503172034.20663B-100000@bats>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

On Sun, 3 May 1998, Sharon Clay wrote:

> This sounds like you have patch1927 on your machine.  That was an
> iR/X/GL patch that had an X bug that would cause all Performer windows
> that were not on pipe 0 to hang.  Performer 2.2 had a WAR in it for this
> and iR patch 2789 will replace patch1927 and fix it.

I have patch 2922 which replaces patch 2789.

I have also tried it under patch 2789.

Still dosen't work.

--TMIV
=======================================================================
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 May  3 16:01:04 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA10364 for info-performer-dist@holodeck.engr.sgi.com; Sun, 3 May 1998 15:51: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 PAA10337 for <info-performer@holodeck.engr.sgi.com>; Sun, 3 May 1998 15:51: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 PAA19865368
	for <info-performer@cthulhu.engr.sgi.com>;
	Sun, 3 May 1998 15:51:49 -0700 (PDT)
Received: from holodeck.gsfc.nasa.gov (holodeck.gsfc.nasa.gov [128.183.33.128]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id PAA09421
	for <info-performer@sgi.com>; Sun, 3 May 1998 15:51:48 -0700 (PDT)
	mail_from (maher@holodeck.gsfc.nasa.gov)
Received: (from maher@localhost) by holodeck.gsfc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA03565 for info-performer@sgi.com; Sun, 3 May 1998 18:51:46 -0400
From: maher@holodeck.gsfc.nasa.gov (Stephen Maher)
Message-Id: <199805032251.SAA03565@holodeck.gsfc.nasa.gov>
Subject: Clipfly hangs Onyx22
To: info-performer@sgi.com
Date: Sun, 3 May 1998 18:51:46 -0400 (EDT)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Status: O

Hi,

Already called this one in to SGI (case 0942235), but thought I'd check the
list. (btw, Mountainview reproduced this problem on their Onyx2)

We've been modifying clipfly and every so often it totally jams our Onyx2
IR - requiring a power cycle.

Turns out that the vanilla 2.2 MR clipfly, with a MR dataset, also flunks.

Running 

clipfly /usr/share/Performer/data/sample.spherepatch

repeatedly will hang after, oh, 3 to 15 times.

AFAIK, we've got pertinent patches.

Any tips?

Thanks,

Steve
--
stephen.maher@gsfc.nasa.gov (301) 286-3368  fax:(301) 286-1776
http://holodeck.gsfc.nasa.gov/vr/vr.html
NASA Goddard Space Flight Center
=======================================================================
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 May  3 17:06:54 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA10582 for info-performer-dist@holodeck.engr.sgi.com; Sun, 3 May 1998 16:48: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 QAA10555 for <info-performer@holodeck.engr.sgi.com>; Sun, 3 May 1998 16:48: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 QAA19823469
	for <info-performer@cthulhu.engr.sgi.com>;
	Sun, 3 May 1998 16:48:19 -0700 (PDT)
Received: from acusoft.com (acusoft.acusoft.com [205.187.235.130]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id QAA18160
	for <info-performer@sgi.com>; Sun, 3 May 1998 16:48:17 -0700 (PDT)
	mail_from (miller@acusoft.com)
Received: from bats by acusoft.com (5.x/SMI-SVR4)
	id AA05226; Sun, 3 May 1998 19:48:16 -0400
Received: by bats (950413.SGI.8.6.12) id TAA20914; Sun, 3 May 1998 19:48:15 -0400
Date: Sun, 3 May 1998 19:48:15 -0400 (EDT)
From: "Thomas M. Miller" <miller@acusoft.com>
X-Sender: miller@bats
To: Sharon Clay <src@rose.engr.sgi.com>
Cc: info-performer@sgi.com, Jesse Liu <liu@acusoft.com>,
        Wentao Lyou <lyou@acusoft.com>
Subject: Re: 2 Pipe Hangup
In-Reply-To: <9805031113.ZM1798@rose.engr.sgi.com>
Message-Id: <Pine.SGI.3.91.980503194454.20906B-100000@bats>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O


Found the Problem!!!!

My second Pipe has 2 channels. I was only assigning a format to channel
1 leaving no format on channel 0. I guess performer 2.2 dosen't like that.

Now if I assign a format on channel 0. Any format at all. Perfly no longer
halts. 

Is that a bug? 

--TMIV

On Sun, 3 May 1998, Sharon Clay wrote:

> This sounds like you have patch1927 on your machine.  That was an
> iR/X/GL patch that had an X bug that would cause all Performer windows
> that were not on pipe 0 to hang.  Performer 2.2 had a WAR in it for this
> and iR patch 2789 will replace patch1927 and fix it.
> 
> src.
=======================================================================
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 May  3 18:32:13 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id SAA10941 for info-performer-dist@holodeck.engr.sgi.com; Sun, 3 May 1998 18:17: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 SAA10914 for <info-performer@holodeck.engr.sgi.com>; Sun, 3 May 1998 18:17: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 SAA18810151
	for <info-performer@cthulhu.engr.sgi.com>;
	Sun, 3 May 1998 18:17:20 -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 SAA02781
	for <info-performer@sgi.com>; Sun, 3 May 1998 18:17:17 -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)
	 id JAA20025; Mon, 4 May 1998 09:16:08 +0800
Received: (from tzelin@localhost) by nuno.singapore.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA15042; Sun, 3 May 1998 18:10:43 -0700
From: "Ong Tze Lin" <tzelin@nuno.singapore.sgi.com>
Message-Id: <9805031810.ZM15040@nuno.singapore.sgi.com>
Date: Sun, 3 May 1998 18:10:43 -0700
In-Reply-To: "Alejandro Saez" <cano@silicon.cl>
        "Re: Extracting terrain data from dxf" (Apr 28,  1:15pm)
References: <199804281534.IAA08013@nuno.singapore.sgi.com> 
	<9804281315.ZM11147@krusty>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: lwillis@inreach.com, "Alejandro Saez" <cano@silicon.cl>
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

Hi

Thanks for all your suggestions.  I've looked into all your suggested URLs.  I
have also found ESRI has a package called ArcTIN which sounds like what I need.

Cheers,
tzelin

On Apr 28, 12:44pm, Lee Willis wrote:
> Subject: Re: Extracting terrain data from dxf
> 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
>

> =======================================================================
> 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 Lee Willis


On Apr 28,  1:15pm, Alejandro Saez wrote:
> Subject: Re: Extracting terrain data from dxf
>
> 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
>-- End of excerpt from Alejandro Saez

> ----------
> > 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

-- 
Ong Tze Lin 				Technical Consultant	
Silicon Graphics ASEAN HQ		High-Performance Computer Graphics
89 Science Park Dr. #03-03 to 06 	
The Rutherford, Singapore 118261	Tel: (065)777 3088  Fax: (065)779 3650      
   
=======================================================================
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 May  4 01:29:58 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id BAA11516 for info-performer-dist@holodeck.engr.sgi.com; Mon, 4 May 1998 01:08: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 BAA11489 for <info-performer@holodeck.engr.sgi.com>; Mon, 4 May 1998 01:08: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 BAA19312299
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 4 May 1998 01:08:25 -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 BAA19949
	for <info-performer@sgi.com>; Mon, 4 May 1998 01:08:22 -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 KAA25963 for <info-performer@sgi.com>; Mon, 4 May 1998 10:08:20 +0200 (MET DST)
Received: from localhost (rfc1413 says jonasa@localhost) by jewel.cs.umu.se (8.8.7/8.8.8) with SMTP id IAA29787 for <info-performer@sgi.com>; Mon, 4 May 1998 08:08:19 GMT
X-Authentication-Warning: jewel.cs.umu.se: jonasa owned process doing -bs
Date: Mon, 4 May 1998 10:08:18 +0200 (MDT)
From: Jonas Andersson <jonasa@cs.umu.se>
To: Performer mailing list <info-performer@sgi.com>
Subject: Virtual cliptexture problems
Message-ID: <Pine.SGI.3.95.980504094515.28418A-100000@jewel.cs.umu.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O


I am using the pfdloader to load a geometry which geostate I then switch
to a new one containing a cliptexture. This works fine.

Problem 1:  
Is it possible to save scene-graphs containing cliptextures to any format?
My attempts to save the created scenegraph fails; the .pfb
file is created but it do not contain neither geometry or cliptexture. 
When saving I get the following warning:

PF Warning:  pfdStoreFile_pfb: Found unregistered pfImageTile read
function 0x588f3c5c. 
PF This function will not be saved. 
PF To have user callback functions saved, 
PF register them with pfdRegisterUserFunc. 


Problem 2:
How can I get rid of the following effect?
When using cliptextures larger then 32768*32768, e.g. virtual
cliptextures, the cliptexture gets distorted. It looks like only a fourth
of the cliptexture (centered around the clipcenter as it changes) can
be displayed correctly. The rest of the cliptexture looks like when
trying to repeat a texture with CLAMPING OFF.

The same cliptexture looks OK when viewed using the .ct-loader.



Problem 3:  Are there anyting I can do enable processor sorting?  When
using cliptextures I get the following message:  

PF Info(2):  Queue proc(8366) started 
PF Notice(3):  MUSTRUN of PFPROC_QUEUE_SORT process -1 on CPU 0 failed. 
PF Warning:  pfQueue::setSortMode; couldn't sproc sortProc, sort mode failed


Thanks in advance for any help!

/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  Mon May  4 04:09:01 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id DAA11853 for info-performer-dist@holodeck.engr.sgi.com; Mon, 4 May 1998 03: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 DAA11826 for <info-performer@holodeck.engr.sgi.com>; Mon, 4 May 1998 03: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 DAA18180114
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 4 May 1998 03:48:42 -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 DAA16536
	for <info-performer@sgi.com>; Mon, 4 May 1998 03:48:39 -0700 (PDT)
	mail_from (abadia@sgonyx.ita.es)
Received: (from abadia@localhost)
	by sgonyx.ita.es (8.8.8/8.8.8) id MAA14138
	for info-performer@sgi.com; Mon, 4 May 1998 12:48:03 +0200 (DST)
From: "Javier Abadia Miranda" <abadia@sgonyx.ita.es>
Message-Id: <9805041248.ZM14136@pandora.ita.es>
Date: Mon, 4 May 1998 12:48:02 +0000
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: info-performer@sgi.com
Subject: Memory space in db loaders
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

Hello:

How is memory space managed in database loaders?

I have written a loader that is dinamically linked
and called with pfdLoadFile() mecanism.

During the app, several files are loaded by subsequent
calls to this pfdLoadFile().

My question is:

If I use static variables inside de loader's code, how many
copies of that variables exist ?

Do they get initialized each time the loader is called?

Otherwise, do they mantain the values from one call to
the next?

Which is the *politically correct* way of keeping
configuration modes, values and attributes from call
to call?

pfdSetConverterMode(someting);
pfdLoadFile(one file);             /* with mode something */
pfdLoadFile(other file);           /* with mode something also */

Thank you!

Aaadios

=======================================================================
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 May  4 06:44:32 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id GAA12173 for info-performer-dist@holodeck.engr.sgi.com; Mon, 4 May 1998 06:29: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 GAA12147 for <info-performer@holodeck.engr.sgi.com>; Mon, 4 May 1998 06:29: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 GAA19713753
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 4 May 1998 06:29:31 -0700 (PDT)
Received: from cse.cuhk.edu.hk (cucs18.cse.cuhk.edu.hk [137.189.91.190]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id GAA16794
	for <info-performer@sgi.com>; Mon, 4 May 1998 06:29:28 -0700 (PDT)
	mail_from (yprj2280@cse.cuhk.edu.hk)
Received: from sparc62.cs.cuhk.hk  by cse.cuhk.edu.hk  with SMTP id VAA12386; Mon, 4 May 1998 21:29:26 +0800 (HKT)
Received: by sparc62.cs.cuhk.hk (SMI-8.6/SMI-SVR4)
	id VAA16767; Mon, 4 May 1998 21:29:25 +0800
Date: Mon, 4 May 1998 21:29:25 +0800 (HKT)
From: vee <yprj2280@cse.cuhk.edu.hk>
X-Sender: yprj2280@sparc62.cs.cuhk.hk
To: info-performer@sgi.com
Message-ID: <Pine.SOL.3.91.980504212439.16632A@sparc62.cs.cuhk.hk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

unsubscribe  info-performer@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 May  4 07:11:06 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA12313 for info-performer-dist@holodeck.engr.sgi.com; Mon, 4 May 1998 07:00: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 HAA12286 for <info-performer@holodeck.engr.sgi.com>; Mon, 4 May 1998 07:00: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 HAA20155270
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 4 May 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 HAA24524
	for <info-performer@sgi.com>; Mon, 4 May 1998 07:00:45 -0700 (PDT)
	mail_from (mcmillan@cambridge.com)
Received: by cavalier.cambridge.com (951211.SGI.8.6.12.PATCH1042/940406.SGI)
	 id JAA10877; Mon, 4 May 1998 09:59:33 -0400
Received: from ds9(192.9.200.40) by cavalier via smap (3.1)
	id xma010869; Mon, 4 May 98 09:59:22 -0400
Received: from ducati.cambridge.com by ds9.cambridge.com (4.1/SMI-4.1-SWS)
	id AA19474; Mon, 4 May 98 09:55:00 EDT
Received: from ducati by ducati.cambridge.com (940816.SGI.8.6.9/SMI-4.1-SWS)
	id JAA11643; Mon, 4 May 1998 09:59:21 -0400
Sender: mcmillan@cambridge.com
Message-Id: <354DC9B8.41C6@cambridge.com>
Date: Mon, 04 May 1998 09:59:20 -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: Eddy Kuo <ekuo@ait.nrl.navy.mil>
Cc: info-performer@sgi.com
Subject: Re: clearify the geoset question
References: <Pine.SGI.3.91.980501173045.24605B-100000@fargo.ait.nrl.navy.mil>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Eddy Kuo wrote:
> 
> Hello:
> 
> I am trying to display a changing geoset into four channels
> each with different view.  I did use a geode to wrap around
> the geoset.
> 
> I put a channel->clear() in my draw callback (otherwise,
> old geometry will no get erase)
> The result is the image keep flashing as if I didn't have
> any double buffering.  This flashing appear even when I
> take out the channel->clear in the draw callback.

Just a long shot: did you try to determine if you had actually
gotten a double buffered visual?  Use something like
pfGetWinFBConfigId on the opened pipewindow and compare it to
the visuals listed when you call /usr/sbin/glxinfo.

Here's an example of the table:

visual ID      double buffered flag
 |                     |
 V                     V
   visual  x  bf lv rg d st  r  g  b a  ax dp st accum buffs  ms 
 id dep cl sp sz l  ci b ro sz sz sz sz bf th cl  r  g  b  a ns b
-----------------------------------------------------------------
0x2c 12 tc  . 12  . r  y  .  4  4  4  .  . 24  . 16 16 16 16  . .
0x2d 12 tc  . 12  . r  y  .  4  4  4  .  . 20  4 16 16 16 16  . .
0x2e 24 tc  . 24  . r  .  .  8  8  8  .  . 24  . 16 16 16 16  . .
0x2f 24 tc  . 24  . r  .  .  8  8  8  .  . 20  4 16 16 16 16  . .
0x31 24 tc  . 24  . r  .  .  8  8  8  .  .  .  . 16 16 16 16  . .

-- 
Scott McMillan                   mailto:mcmillan@cambridge.com
Cambridge Research Associates    http://www.cambridge.com
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 May  4 11:53:34 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA13051 for info-performer-dist@holodeck.engr.sgi.com; Mon, 4 May 1998 11:40: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 LAA13024 for <info-performer@holodeck.engr.sgi.com>; Mon, 4 May 1998 11:40: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 LAA20246868
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 4 May 1998 11:40:48 -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 LAA20426
	for <info-performer@sgi.com>; Mon, 4 May 1998 11:40:42 -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 LAA00848; Mon, 4 May 1998 11:48:59 -0700 (PDT)
From: Jan Barglowski <jan@archimedes.vislab.navy.mil>
Posted-Date: Mon, 4 May 1998 11:48:59 -0700 (PDT)
Message-Id: <199805041848.LAA00848@archimedes.vislab.navy.mil>
Subject: Re: Virtual cliptexture problems
To: jonasa@cs.umu.se (Jonas Andersson)
Date: Mon, 4 May 1998 11:48:59 -0700 (PDT)
Cc: info-performer@sgi.com
In-Reply-To: <Pine.SGI.3.95.980504094515.28418A-100000@jewel.cs.umu.se> from "Jonas Andersson" at May 4, 98 10:08:18 am
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

Jonas Andersson wrote:
> I am using the pfdloader to load a geometry which geostate I then switch
> to a new one containing a cliptexture. This works fine.
> 
> Problem 1:  
> Is it possible to save scene-graphs containing cliptextures to any format?
> My attempts to save the created scenegraph fails; the .pfb
> file is created but it do not contain neither geometry or cliptexture. 
> When saving I get the following warning:

Unfortunately, cliptextures can't be saved to a .pfb file.  I think
(not sure) it may have something to do with the texgen matrix.  Hopefully
this can be implemented in the next version of Performer?
 
> Problem 2:
> How can I get rid of the following effect?
> When using cliptextures larger then 32768*32768, e.g. virtual
> cliptextures, the cliptexture gets distorted. It looks like only a fourth
> of the cliptexture (centered around the clipcenter as it changes) can
> be displayed correctly. The rest of the cliptexture looks like when
> trying to repeat a texture with CLAMPING OFF.

> The same cliptexture looks OK when viewed using the .ct-loader.

Of course, you know that if you're using larger than 32k cliptextures,
you must manage the LODOffset yourself!  The .ct loader automatically 
deals with virtual cliptextures by adjusting the LODOffset for each
concentric "ring" of geometry (turn on wireframe and see).  To see if
this is your problem, turn on the "Offset" button from Auto to "="
and you should see some serious smearing on the cliptexture.

For a good explanation of how to manage virtual cliptexture, see the
Performer manual, plus virtcliptexture.c and the .ct loader.  I 
have developed a technique for using .flt terrains and virtual 
cliptextures if you need it.

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 May  4 13:30:24 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA13358 for info-performer-dist@holodeck.engr.sgi.com; Mon, 4 May 1998 13:18: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 NAA13331 for <info-performer@holodeck.engr.sgi.com>; Mon, 4 May 1998 13:18: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 NAA19924216
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 4 May 1998 13:18:26 -0700 (PDT)
Received: from sunu450.rz.ruhr-uni-bochum.de (sunu450.rz.ruhr-uni-bochum.de [134.147.222.33]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id NAA00226
	for <info-performer@sgi.com>; Mon, 4 May 1998 13:18:22 -0700 (PDT)
	mail_from (Bert.Grollmann@rz.ruhr-uni-bochum.de)
Message-Id: <199805042018.NAA00226@sgi.sgi.com>
Received: (qmail 14976 invoked from network); 4 May 1998 20:18:16 -0000
Received: from dialppp-3-171.rz.ruhr-uni-bochum.de (HELO pc0001) (134.147.3.171)
  by mailhost.rz.ruhr-uni-bochum.de with SMTP; 4 May 1998 20:18:16 -0000
X-Sender: grollbbo@mailhost.rz.ruhr-uni-bochum.de
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Mon, 04 May 1998 22:16:47 +0200
To: info-performer@sgi.com
From: "B. Grollmann" <Bert.Grollmann@rz.ruhr-uni-bochum.de>
Subject: Inventor loader
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Status: O

Hi Performers ;-))

I've a question about the performer IV loader (Perf 2.2).
After loading geometry and textures with alpha channel,
I can't see the transparency..is there a bug (the wavefront loader works fine)
or have I to do some -special- work ?
And,- the textures loaded seems to look like 16Bit colors (or less)
and they have definitely 24Bit (RGBA=32Bit)...another bug...or -special-
work ;-)))

Thanks for all you help ;-)))
    Bert





        It's up to us to virtualise your environment !
        ..............................................
    Bert Grollmann   mailto:Bert.Grollmann@Ruhr-Uni-Bochum.de
		       mailto:Bert.Grollmann@FH-Bochum.de      
 ======================================================================
    RUB - Ruhr University Bochum
    FH  - Polytechnical Institute of Bochum
          Dept. for artificial intelligence, system software 
                and graphic systems
                kiss-lab

    Lennershofstr. 140 
    44801 Bochum 
    Germany 
 ======================================================================
=======================================================================
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 May  4 13:39:48 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA13406 for info-performer-dist@holodeck.engr.sgi.com; Mon, 4 May 1998 13:31: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 NAA13379 for <info-performer@holodeck.engr.sgi.com>; Mon, 4 May 1998 13:31: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 NAA20246641
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 4 May 1998 13:31:12 -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 NAA06406
	for <info-performer@sgi.com>; Mon, 4 May 1998 13:31:10 -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 NAA00541; Mon, 4 May 1998 13:42:10 -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 UAA07991; Mon, 4 May 1998 20:32:20 GMT
Received: (from marcus@localhost) by logan.engr.multigen.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA09035; Mon, 4 May 1998 13:32:15 -0700
From: "Marcus Barnes" <marcus@multigen.com>
Message-Id: <9805041332.ZM9033@logan.engr.multigen.com>
Date: Mon, 4 May 1998 13:32:14 -0700
In-Reply-To: Stuart Levy <slevy@ncsa.uiuc.edu>
        "Performer 2.2 "compat" libraries ineffective?" (May  1, 11:14am)
References: <199805011614.LAA05725@impact13.ncsa.uiuc.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: Performer 2.2 "compat" libraries ineffective?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On May 1, 11:14am, Stuart Levy wrote:
>As Bill Sherman has been explaining recently, we've been having
>a good deal of trouble with applications which worked under Performer 2.0
>and 2.1 and now misbehave when run in a Performer 2.2 environment,
>even though the Perf 2.2 "compatibility" packages have been installed.
>
>(2) Still, these apps lose material properties (color and transparency)
>    on objects they display, i.e., simple colored objects are rendered
>    as opaque gray (probably actually white).

We see this with lighting enabled. With lighting disabled, correct colors and
transparency return.

>    Textured objects are textured pretty much as expected, although
>    the textures appear opaque (so e.g. billboarded trees become opaque
>    rectangles with trees pasted on them!).
>
>    Lighting looks reasonable and may be correct, though it's just the
>    environment's lighting; the objs we load don't include their own lights.

No. We see lighting broken as described in your first paragraph.

>    The incompatibility appears to lie somewhere in the compat-mode
>    /usr/lib/libpf_ogl.so.{2,3} libraries as distributed with Performer 2.2.
>    If we just *replace* these with /usr/lib/libpf_ogl.so.{2,3}
>    as copied from a system with Performer 2.{0,1} installed,
>    that's sufficient to make material properties behave normally again.
>    [They needn't be replaced in situ in /usr/lib; it's enough to put the
>     appropriate libpf_ogl.so somewhere and point LD_LIBRARY_PATH at it.]

We here at MultiGen have reproduced these problems using both SmartScene and
perfly. The performer_eoe.compat subsytem DSO's, as shipped with Performer 2.2,
are BROKEN as described above. They are unusable.

A simple test is simply to run perfly with no command line arguments. The "Iris
Performer" text on the opening screen is the wrong color (greyish).

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 May  4 14:40:26 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA13787 for info-performer-dist@holodeck.engr.sgi.com; Mon, 4 May 1998 14:34:52 -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 OAA13760 for <info-performer@holodeck.engr.sgi.com>; Mon, 4 May 1998 14:34:51 -0700
Received: (from gischer@localhost) by puget.engr.sgi.com (980205.SGI.8.8.8/960327.SGI.AUTOCF) id OAA45083; Mon, 4 May 1998 14:34:51 -0700 (PDT)
Date: Mon, 4 May 1998 14:34:51 -0700 (PDT)
Message-Id: <199805042134.OAA45083@puget.engr.sgi.com>
From: Jay Gischer <gischer@puget.engr.sgi.com>
To: "Javier Abadia Miranda" <abadia@sgonyx.ita.es>
cc: info-performer@puget.engr.sgi.com
Subject: Memory space in db loaders
In-Reply-To: <9805041248.ZM14136@pandora.ita.es>
References: <9805041248.ZM14136@pandora.ita.es>
Status: O


Javier Abadia Miranda writes:
 > Hello:
 > 
 > How is memory space managed in database loaders?
 > 
 > I have written a loader that is dinamically linked
 > and called with pfdLoadFile() mecanism.
 > 
 > During the app, several files are loaded by subsequent
 > calls to this pfdLoadFile().
 > 
 > My question is:
 > 
 > If I use static variables inside de loader's code, how many
 > copies of that variables exist ?
 > 
One of each.

 > Do they get initialized each time the loader is called?
 > 
No.  Well, they do if you wrote the code to initialize them each time
you open a new file, but then you wouldn't be asking the question,
would you?

 > Otherwise, do they mantain the values from one call to
 > the next?
 > 
Yes.  
Well, there's one thing I don't know for sure, and that is if
Performer ever unlinks a dynamically linked loader.  I don't think it
does, but I haven't verified it, and if it does, then the answer is
"No, sometimes they don't."

 > Which is the *politically correct* way of keeping
 > configuration modes, values and attributes from call
 > to call?
 > 
 > pfdSetConverterMode(someting);
 > pfdLoadFile(one file);             /* with mode something */
 > pfdLoadFile(other file);           /* with mode something also */
 > 
Dunno about politics, but using a static variable (or a static member
variable) should work just fine.

=======================================================================
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 May  4 14:40:26 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA13816 for info-performer-dist@holodeck.engr.sgi.com; Mon, 4 May 1998 14:38: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 OAA13789 for <info-performer@holodeck.engr.sgi.com>; Mon, 4 May 1998 14:38: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 OAA20245555
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 4 May 1998 14:38:29 -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 OAA07985
	for <info-performer@sgi.com>; Mon, 4 May 1998 14:38:28 -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 RAA23834
	for <info-performer@sgi.com>; Mon, 4 May 1998 17:38:26 -0400 (EDT)
Date: Mon, 4 May 1998 17:38:26 -0400 (EDT)
From: Eddy Kuo <ekuo@ait.nrl.navy.mil>
To: info-performer@sgi.com
Subject: More geoset flashing problem.
Message-ID: <Pine.SGI.3.91.980504172205.2449C-100000@fargo.ait.nrl.navy.mil>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

Hello:

Thanks for the advices.  The problem is partially solved.
First let me state what I have changed
	i)  I am using double buffering, this is checked
            from the visualID for my pfPipeWindow
	ii) I am using immediate draw mode.
	    This is done by calling 
		setDrawMode(PFGS_COMPILE_GL, PF_OFF)
  		setDrawMode(PFGS_DRAW_GLOBJ, PF_ON)
	    for each geoset
        iii) I am running the program on a IR, Onyx II 
             two pipes machine.  Each pipe renders
             two channels
	iv)  Set the initial iseg mask to 0 (since I
             am not doing any intersection right now)
             by calling:
        grotto_obj->root[i]->setTravMask(PFTRAV_ISECT, 0x0,
				       PFTRAV_SELF|PFTRAV_DESCEND,
   					PF_SET);
 	v) update the bounding box whenever the geoset geometry
           changes.  This is done by:
           gset->setBound((pfBox*)NULL, PFBOUND_DYNAMIC);

After all these changes, image on my master channel is fine for the
most part, and the image on the other channels are still flashing.
And I notice the flashing only happen when my geoset has more than
one primitives.

Thanks for any advice.

Ed.



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

=======================================================================
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 May  4 14:40:26 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA13758 for info-performer-dist@holodeck.engr.sgi.com; Mon, 4 May 1998 14:33: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 OAA13731 for <info-performer@holodeck.engr.sgi.com>; Mon, 4 May 1998 14:33: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 OAA20044079
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 4 May 1998 14:33:27 -0700 (PDT)
Received: from lobotomy.evt.com ([204.133.157.33]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id OAA06037
	for <info-performer@sgi.com>; Mon, 4 May 1998 14:33:24 -0700 (PDT)
	mail_from (herod@evt.com)
Received: from evt.com (localhost [127.0.0.1]) by lobotomy.evt.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA03498 for <info-performer@sgi.com>; Mon, 4 May 1998 15:33:21 -0600
Sender: herod@evt.com
Message-ID: <354E3421.844660C2@evt.com>
Date: Mon, 04 May 1998 15:33:21 -0600
From: Scott Herod <herod@evt.com>
X-Mailer: Mozilla 4.04 [en] (X11; I; IRIX 6.3 IP32)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: freeing memory allocated with pfuDownloadTexList()
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

We use

 pfuDownloadTexList( pfuMakeSceneTexList(scene), PFUTEX_APPLY );

to preload textures in a scene.  How can we clean up by freeing
the space used by textures when they are no longer used in a scene
graph.

Thank you,
Scott Herod
herod@evt.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 May  4 15:25:50 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA14183 for info-performer-dist@holodeck.engr.sgi.com; Mon, 4 May 1998 15:06: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 PAA14156 for <info-performer@holodeck.engr.sgi.com>; Mon, 4 May 1998 15:06: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 PAA20108264
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 4 May 1998 15:06:37 -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 PAA19948
	for <info-performer@sgi.com>; Mon, 4 May 1998 15:06:35 -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 RAA22883 for <info-performer@sgi.com>; Mon, 4 May 1998 17:06:28 -0500 (EST)
Message-Id: <3.0.32.19980504171249.006adf9c@mail.bur.visidyne.com>
X-Sender: sartor@mail.bur.visidyne.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 04 May 1998 17:12:50 -0500
To: info-performer@sgi.com
From: ken sartor <sartor@visidyne.com>
Subject: rgba file formats
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Status: O


Hi -

I realize this is a bit off topic but...

Does anyone know the exact format of a RGBA file?  By this
i mean both what ancillary information is written (e.g.,
interleaved, sequential, separate) and how the RGBA values
are written (e.g., 0-255, 0-1.0, other). 

A code snippet or a pointer to useful docs would be greatly 
appreciated!!!

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  Mon May  4 16:09:37 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA14447 for info-performer-dist@holodeck.engr.sgi.com; Mon, 4 May 1998 15:48: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 PAA14420 for <info-performer@holodeck.engr.sgi.com>; Mon, 4 May 1998 15:48: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 PAA17490927
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 4 May 1998 15:48:09 -0700 (PDT)
Received: from acusoft.com (acusoft.acusoft.com [205.187.235.130]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id PAA06875
	for <info-performer@sgi.com>; Mon, 4 May 1998 15:48:07 -0700 (PDT)
	mail_from (miller@acusoft.com)
Received: from bats by acusoft.com (5.x/SMI-SVR4)
	id AA10519; Mon, 4 May 1998 18:48:06 -0400
Received: by bats (950413.SGI.8.6.12) id SAA25271; Mon, 4 May 1998 18:48:05 -0400
Date: Mon, 4 May 1998 18:48:05 -0400 (EDT)
From: "Thomas M. Miller" <miller@acusoft.com>
X-Sender: miller@bats
To: ken sartor <sartor@visidyne.com>
Cc: info-performer@sgi.com
Subject: Re: rgba file formats
In-Reply-To: <3.0.32.19980504171249.006adf9c@mail.bur.visidyne.com>
Message-Id: <Pine.SGI.3.91.980504184455.25263A@bats>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O


Check out http://www.dcs.ed.ac.uk/%7Emxr/gfx/2d/RGB.txt

and there is always the image library /usr/include/gl/image.h and /usr/lib/libimage.a

Both of these written by Paul Haeberli


--TMIV

=======================================================================
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 May  5 18:01:41 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id RAA01024 for info-performer-dist@holodeck.engr.sgi.com; Tue, 5 May 1998 17:57: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 RAA00996 for <info-performer@holodeck.engr.sgi.com>; Tue, 5 May 1998 17:57: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 AAA19771393
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 5 May 1998 00:22:27 -0700 (PDT)
Received: from sunu450.rz.ruhr-uni-bochum.de (sunu450.rz.ruhr-uni-bochum.de [134.147.222.33]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id AAA08441
	for <info-performer@sgi.com>; Tue, 5 May 1998 00:22:23 -0700 (PDT)
	mail_from (Bert.Grollmann@rz.ruhr-uni-bochum.de)
Message-Id: <199805050722.AAA08441@sgi.sgi.com>
Received: (qmail 8954 invoked from network); 5 May 1998 07:22:20 -0000
Received: from dialppp-5-51.rz.ruhr-uni-bochum.de (HELO pc0001) (134.147.5.51)
  by mailhost.rz.ruhr-uni-bochum.de with SMTP; 5 May 1998 07:22:20 -0000
X-Sender: grollbbo@mailhost.rz.ruhr-uni-bochum.de
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Tue, 05 May 1998 09:22:09 +0200
To: info-performer@sgi.com
From: "B. Grollmann" <Bert.Grollmann@rz.ruhr-uni-bochum.de>
Subject: Inventor loader
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Status: O

Hi Performers ;-))

I've a question about the performer IV loader (Perf 2.2).
After loading geometry and textures with alpha channel,
I can't see the transparency..is there a bug (the wavefront loader works fine)
or have I to do some -special- work ?
And,- the textures loaded seems to look like 16Bit colors (or less)
and they have definitely 24Bit (RGBA=32Bit)...another bug...or -special-
work ;-)))

Thanks for all you help ;-)))
    Bert





        It's up to us to virtualise your environment !
        ..............................................
    Bert Grollmann   mailto:Bert.Grollmann@Ruhr-Uni-Bochum.de
		       mailto:Bert.Grollmann@FH-Bochum.de      
 ======================================================================
    RUB - Ruhr University Bochum
    FH  - Polytechnical Institute of Bochum
          Dept. for artificial intelligence, system software 
                and graphic systems
                kiss-lab

    Lennershofstr. 140 
    44801 Bochum 
    Germany 
 ======================================================================
=======================================================================
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 May  5 18:01:41 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id RAA00986 for info-performer-dist@holodeck.engr.sgi.com; Tue, 5 May 1998 17:56: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 RAA00956 for <info-performer@holodeck.engr.sgi.com>; Tue, 5 May 1998 17:56: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 BAA19790830
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 5 May 1998 01:36:04 -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 BAA21851
	for <info-performer@sgi.com>; Tue, 5 May 1998 01:35:57 -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 KAA03980
	for <info-performer@sgi.com>; Tue, 5 May 1998 10:35:41 +0200 (MET DST)
Received: by segolene.roazhon.inra.fr (5.x/SMI-SVR4)
	id AA19761; Tue, 5 May 1998 10:37:08 +0200
Date: Tue, 5 May 1998 10:37:08 +0200
Message-Id: <9805050837.AA19761@segolene.roazhon.inra.fr>
To: info-performer@sgi.com
Subject: pfAsdConfig vs pfASDFaceBBox (bis)
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  Tue May  5 18:03:18 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id SAA01230 for info-performer-dist@holodeck.engr.sgi.com; Tue, 5 May 1998 18:02:28 -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 SAA01200 for <info-performer@holodeck.engr.sgi.com>; Tue, 5 May 1998 18:02: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 KAA19491368
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 5 May 1998 10:48:43 -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 KAA26964
	for <info-performer@sgi.com>; Tue, 5 May 1998 10:48:42 -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 AAA29382
          for <info-performer@sgi.com>; Tue, 5 May 1998 13:47:12 -0400
Message-ID: <354F50FA.BDF4FB00@bah.com>
Date: Tue, 05 May 1998 13:48:43 -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: sharper image
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Hello pfpeople;

I'm need to map a sharp detailed texture onto a terrain that will be
used for a slow

moving vehicle.  The desert texture is detailed enough to convince a
flight simulator

crew,but not the low level folks. the closer to the ground the fuzzer it

gets. if I map

it smaller (more texels that polys) it produces a "tiled" effect(ie. you
could see the edges of
 the scanned image)
  I've tried different filters w/o any luck. If  I'm missing a
procedure please

enlighten...my clock is running!! GULP!

thanks

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  Tue May  5 17:52:28 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA14504 for info-performer-dist@holodeck.engr.sgi.com; Mon, 4 May 1998 16:09: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 QAA14477 for <info-performer@holodeck.engr.sgi.com>; Mon, 4 May 1998 16:09: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 QAA20236518
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 4 May 1998 16:09:47 -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 QAA15449
	for <info-performer@sgi.com>; Mon, 4 May 1998 16:09:42 -0700 (PDT)
	mail_from (cano@silicon.cl)
Mtz-Posted-Date: Mon, 4 May 1998 20:09:14 -0700
Received: from ivory.silicon.cl(200.29.40.2) by challenge via smap (3.1)
	id xma011164; Mon, 4 May 98 20:08:55 -0700
Received: from krusty (krusty [200.29.40.72]) by silicon.cl (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA27391; Mon, 4 May 1998 19:15:22 -0400
Received: (from cano@localhost) by krusty (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA16250; Mon, 4 May 1998 19:22:47 -0400
From: "Alejandro Saez" <cano@silicon.cl>
Message-Id: <9805041922.ZM16248@krusty>
Date: Mon, 4 May 1998 19:22:47 -0400
In-Reply-To: William Sherman -Visualization <wsherman@ncsa.uiuc.edu>
        "Re: Performer 2.2 "compat" libraries ineffective?" (May  1,  3:54pm)
References: <199805012054.PAA11097@space.ncsa.uiuc.edu>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: William Sherman -Visualization <wsherman@ncsa.uiuc.edu>
Subject: Re: Performer 2.2 "compat" libraries ineffective?
Cc: info-performer@sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On May 1,  3:54pm, William Sherman -Visualization wrote:
> Subject: Re: Performer 2.2 "compat" libraries ineffective?
> > On May 1, 11:14am, Stuart Levy wrote:
> > >(1) Some apps compiled & linked in a Performer 2.0/2.1 environment refuse
to
> > >    find (for example) iv and iv20 loaders, even though the corresponding
> > >    libpfiv_ogl.so and libpfiv20_ogl.so libraries exist and are
successfully
> > >    opened by the app, according to par(1).
>
> And by the way, odd behaviour was exhibited by more than one application,
> some of which hadn't been compiled in a year or so.  And a few of which
> we were given only the executable, so recompiling is not even an option.
>
Remember that you are probably using dynamic loading of the libraries (done by
rld as noted by Marcus) which mean that although you haven't recompiled things
have changed.


-- 
------------------------------------------------------------------------
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 May  5 18:01:41 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id RAA01145 for info-performer-dist@holodeck.engr.sgi.com; Tue, 5 May 1998 17:59: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 RAA01117 for <info-performer@holodeck.engr.sgi.com>; Tue, 5 May 1998 17:59: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 KAA19644116
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 5 May 1998 10:57:57 -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 KAA01122
	for <info-performer@sgi.com>; Tue, 5 May 1998 10:57:56 -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 KAA18792024;
	Tue, 5 May 1998 10:57:55 -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 KAA01736; Tue, 5 May 1998 10:57:46 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <354F531A.EA75E0C8@sgi.com>
Date: Tue, 05 May 1998 10:57:46 -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: "Charlie H. Chang" <a00chc00@nchc.gov.tw>
CC: info-performer@sgi.com
Subject: Re: drawing wireframe...
References: <35484281.945C41D1@nchc.gov.tw>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Charlie H. Chang wrote:
> 
> 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!

Just add some axes in a geode->geoset at the origin below
each dcs.

This should mark the resulting translation and orientation
of the DCS in eye space.

If you want to be really fancy you could add geometry to
the parent which had a line from it's origin to each child
dcs by starting at 0,0,0 and transforming the end point
(also 0,0,0) through the matrix of the child dcs, this
would draw a 3D graph of the pfDCS connections.

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 May  5 18:14:48 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id SAA01822 for info-performer-dist@holodeck.engr.sgi.com; Tue, 5 May 1998 18:10: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 SAA01762 for <info-performer@holodeck.engr.sgi.com>; Tue, 5 May 1998 18:10: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 FAA20334454
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 5 May 1998 05:00:11 -0700 (PDT)
Received: from relay4.smtp.psi.net (relay4.smtp.psi.net [38.9.52.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id FAA27852
	for <info-performer@sgi.com>; Tue, 5 May 1998 05:00:10 -0700 (PDT)
	mail_from (gwaldron@peril.com)
Received: from [38.181.237.15] (helo=killer)
	by relay4.smtp.psi.net with smtp (Exim 1.90 #1)
	id 0yWgOG-0006sl-00; Tue, 5 May 1998 08:00:09 -0400
Message-ID: <003b01bd781e$01e3cbe0$0fedb526@killer.potomacinstitute.com>
From: "Glenn Waldron" <gwaldron@peril.com>
To: <info-performer@sgi.com>, "ken sartor" <sartor@visidyne.com>
Subject: Re: rgba file formats
Date: Tue, 5 May 1998 08:04:48 -0400
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

OK, forgot the URL!  The RGBA loader code is at:

 http://www.peril.com/ftp/rgb_loader.tar.gz

enjoy- glenn.
--
Glenn Waldron, Peril Technologies * gwaldron@peril.com 703.598.7835

-----Original Message-----
From: ken sartor <sartor@visidyne.com>
To: info-performer@sgi.com <info-performer@sgi.com>
Date: Monday, May 04, 1998 6:44 PM
Subject: rgba file formats


>
>Hi -
>
>I realize this is a bit off topic but...
>
>Does anyone know the exact format of a RGBA file?  By this
>i mean both what ancillary information is written (e.g.,
>interleaved, sequential, separate) and how the RGBA values
>are written (e.g., 0-255, 0-1.0, other). 
>
>A code snippet or a pointer to useful docs would be greatly 
>appreciated!!!
>
>ken
>=======================================================================
>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 May  5 18:14:50 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id SAA01354 for info-performer-dist@holodeck.engr.sgi.com; Tue, 5 May 1998 18:04: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 SAA01323 for <info-performer@holodeck.engr.sgi.com>; Tue, 5 May 1998 18:04: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 KAA20711977
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 5 May 1998 10:21: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 KAA15163
	for <info-performer@sgi.com>; Tue, 5 May 1998 10:21:09 -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 KAA18592697;
	Tue, 5 May 1998 10:21:06 -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 KAA01684; Tue, 5 May 1998 10:21:05 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <354F4A81.99989D86@sgi.com>
Date: Tue, 05 May 1998 10:21:05 -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: wbethel@r3vis.com
CC: info-performer@sgi.com
Subject: Re: OGL++
References: <199804271923.MAA27862@shell8.ba.best.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Wes Bethel wrote:
> 
> >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, ??]"?

Everyone is free to do what they like. SGI only has one vote on
the ARB. Most of the short list is involved with FSG.

> 
> 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.
> 

Probably not.

> Is there another forum for this besides the performer list?

:-)


-- 
"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 May  5 18:14:51 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id SAA01742 for info-performer-dist@holodeck.engr.sgi.com; Tue, 5 May 1998 18:10: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 SAA01712 for <info-performer@holodeck.engr.sgi.com>; Tue, 5 May 1998 18:10: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 FAA20679404
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 5 May 1998 05:40:52 -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 FAA06293
	for <info-performer@sgi.com>; Tue, 5 May 1998 05:40:50 -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 HAA26869; Tue, 5 May 1998 07:40:16 -0500 (CDT)
Date: Tue, 5 May 1998 07:39:05 -0500 (CDT)
From: Steve Baker <sbaker@link.com>
X-Sender: steve@sutcliffe.bgm.link.com
Reply-To: Steve Baker <sbaker@link.com>
To: ken sartor <sartor@visidyne.com>
cc: info-performer@sgi.com
Subject: Re: rgba file formats
In-Reply-To: <3.0.32.19980504171249.006adf9c@mail.bur.visidyne.com>
Message-ID: <Pine.SGI.3.96.980505073539.11872C-100000@sutcliffe.bgm.link.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

On Mon, 4 May 1998, ken sartor wrote:

> Does anyone know the exact format of a RGBA file?  By this
> i mean both what ancillary information is written (e.g.,
> interleaved, sequential, separate) and how the RGBA values
> are written (e.g., 0-255, 0-1.0, other). 
> 
> A code snippet or a pointer to useful docs would be greatly 
> appreciated!!!

Here you go ... everything you ever need to know.

==============================================================
The SGI Image File Format.

Draft version 0.9

Paul Haeberli (paul@sgi.com) Silicon Graphics Computer Systems

INTRODUCTION.

This is the definitive document describing the SGI image file format. This is a low level spec that
describes the actual byte level format of SGI image files. On SGI machines the preferred way of
reading and writing SGI image files is to use the image library -limage. This library provides a set
of functions that make it easy to read and write SGI images. If you are on an SGI workstation you
can get info on -limage by doing: 


    % man 4 rgb


A note on byte order of values in the SGI image files

In the following description a notation like bits[7..0] is used to denote a range of bits in a binary
value. Bit 0 is the lowest order bit in a the value. 

All short values are represented by 2 bytes. The first byte stores the high order 8 bits of the value:
bits[15..8]. The second byte stores the low order 8 bits of the value: bits[7..0]. 

So, this function will read a short value from the file: 

            unsigned short getshort(inf)
            FILE *inf;
            {
                unsigned char buf[2];

                fread(buf,2,1,inf);
                return (buf[0]<<8)+(buf[1]<<0);
            }

All long values are represented by 4 bytes. The first byte stores the high order 8 bits of the value:
bits[31..24]. The second byte stores bits[23..16]. The third byte stores bits[15..8]. The forth byte
stores the low order 8 bits of the value: bits[7..0]. 

So, this function will read a long value from the file: 

            static long getlong(inf)
            FILE *inf;
            {
                unsigned char buf[4];

                fread(buf,4,1,inf);
                return (buf[0]<<24)+(buf[1]<<16)+(buf[2]<<8)+(buf[3]<<0);
            }

GENERAL STRUCTURE

The general structure of an SGI image file is as shown below: 

    The header indicates whether the image is run length encoded (RLE). 
    If the image is not run length encoded, this is the structure: 

            The Header
            The Image Data

    If the image is run length encoded, this is the structure: 

            The Header
            The Offset Tables 
            The Image Data

The Header

The header consists of the following: 

       Size  | Type   | Name      | Description   

     2 bytes | short  | MAGIC     | IRIS image file magic number
     1 byte  | char   | STORAGE   | Storage format
     1 byte  | char   | BPC       | Number of bytes per pixel channel 
     2 bytes | ushort | DIMENSION | Number of dimensions
     2 bytes | ushort | XSIZE     | X size in pixels 
     2 bytes | ushort | YSIZE     | Y size in pixels 
     2 bytes | ushort | ZSIZE     | Number of channels
     4 bytes | long   | PIXMIN    | Minimum pixel value
     4 bytes | long   | PIXMAX    | Maximum pixel value
     4 bytes | char   | DUMMY     | Ignored
    80 bytes | char   | IMAGENAME | Image name
     4 bytes | long   | COLORMAP  | Colormap ID
   404 bytes | char   | DUMMY     | Ignored

Here is a description of each field in the image file header: 

    MAGIC - This is the decimal value 474 saved as a short. This identifies the file as an SGI
    image file. 
    STORAGE - specifies whether the image is stored using run length encoding (RLE) or not
    (VERBATIM). If RLE is used, the value of this byte will be 1. Otherwise the value of this
    byte will be 0. The only allowed values for this field are 0 and 1. 
    BPC - describes the precision that is used to store each channel of an image. This is the
    number of bytes per pixel component. The majority of SGI image files use 1 byte per pixel
    component, giving 256 levels. Some SGI image files use 2 bytes per component. The only
    allowed values for this field are 1 and 2. 
    DIMENSION - described the number of dimensions in the data stored in the image file. The
    only allowed values are 1, 2, or 3. If this value is 1, the image file consists of only 1 channel
    and only 1 scanline. The length of this scan line is given by the value of XSIZE below. If this
    value is 2, the file consists of a single channel with a number of scan lines. The width and
    height of the image are given by the values of XSIZE and YSIZE below. If this value is 3,
    the file consists of a number of channels. The width and height of the image are given by the
    values of XSIZE and YSIZE below. The number of channels is given by the value of ZSIZE
    below. 
    XSIZE - The width of the image in pixels 
    YSIZE - The height of the image in pixels 
    ZSIZE - The number of channels in the image. B/W images are stored as 2 dimensional
    images with a ZSIZE or 1. RGB color images are stored as 3 dimensional images with a
    ZSIZE of 3. An RGB image with an ALPHA channel is stored as a 3 dimensional image
    with a ZSIZE of 4. There are no inherent limitations in the SGI image file format that would
    preclude the creation of image files with more than 4 channels. 
    PINMIN - The minimum pixel value in the image. The value of 0 may be used if no pixel
    has a value that is smaller than 0. 
    PINMAX - The maximum pixel value in the image. The value of 255 may be used if no
    pixel has a value that is greater than 255. This is the value that is considered to be full
    brightness in the image. 
    DUMMY - This 4 bytes of data should be set to 0. 
    IMAGENAME - An null terminated ascii string of up to 79 characters terminated by a null
    may be included here. This is not commonly used. 
    COLORMAP - This controls how the pixel values in the file should be interpreted. It can
    have one of these four values: 
        0: NORMAL - The data in the channels represent B/W values for images with 1
        channel, RGB values for images with 3 channels, and RGBA values for images with 4
        channels. Almost all the SGI image files are of this type. 
        1: DITHERED - The image will have only 1 channel of data. For each pixel, RGB
        data is packed into one 8 bit value. 3 bits are used for red and green, while blue uses 2
        bits. Red data is found in bits[2..0], green data in bits[5..3], and blue data in bits[7..6].
        This format is obsolete. 
        2: SCREEN - The image will have only 1 channel of data. This format was used to
        store color-indexed pixels. To convert the pixel values into RGB values a colormap
        must be used. The appropriate color map varies from image to image. This format is
        obsolete. 
        3: COLORMAP - The image is used to store a color map from an SGI machine. In
        this case the image is not displayable in the conventional sense. 
    DUMMY - This 404 bytes of data should be set to 0. This makes the header exactly 512
    bytes. 

The Image Data (if not RLE)

If the image is stored verbatim (without RLE), the image data directly follows the 512 byte header.
The data for each scanline in the first channel is written first. If the image has more than 1 channel
the remaining channels follow the first channel in numerical order. If the BPC value is 1, then each
scan line is written as XSIZE bytes. If the BPC value is 2, then each scanline is written as XSIZE
shorts. These shorts are stored in the byte order described above. 

The Offset Tables (if RLE)

If the image is stored using run length encoding, offset tables follow the header that describe what
the file offsets are to the RLE for each scanline. This information only applies if the value for
STORAGE above is 1. 

            Size  | Type   | Name      | Description   

     tablen longs | long   | STARTTAB  | Start table
     tablen longs | long   | LENGTHTAB | Length table

One entry in each table is needed for each scan line of RLE data. The total number of scanlines in
the image (tablen) is determined by the product of the YSIZE and ZSIZE. There are two tables of
longs that are written. Each consists of tablen longs of data. The first table has the file offsets to
the RLE data for each scan line in the image. In a file with more than 1 channel (ZSIZE > 1) this
table first has all the offsets for the scanlines in the first channel, followed be offsets for the
scanlines in the second channel, etc. The second table has the RLE data length for each scan line in
the image. In a file with more than 1 channel (ZSIZE > 1) this table first has all the RLE data
lengths for the scanlines in the first channel, followed be RLE data lengths for the scanlines in the
second channel, etc. 

To find the the file offset, and the number of bytes in the RLE data for a particular scanline, these
two arrays may be read in and indexed as follows: 

To read in the tables: 

            unsigned long *starttab, *lengthtab;

            tablen = ysize*zsize*sizeof(long);
            starttab = (unsigned long *)mymalloc(tablen);
            lengthtab = (unsigned long *)mymalloc(tablen);
            fseek(inf,512,SEEK_SET);
            readlongtab(inf,starttab);
            readlongtab(ing,lengthtab);

To find the file offset and RLE data length for a scanline: 

            rowno is an integer in the range 0 to YSIZE-1
            channo is an integer in the range 0 to ZSIZE-1

            rleoffset = starttab[rowno+channo*YSIZE]
            rlelength = lengthtab[rowno+channo*YSIZE]

The Image Data (if RLE)

This information only applies if the value for STORAGE above is 1. If the image is stored using
run length encoding, the image data follows the offset tables above. The RLE data is not in any
particular order. The offset tables above are used to locate the rle data for any scanline. 

The RLE data must be read in from the file and expanded into pixel data in the following manner: 

If BPC is 1, then there is one byte per pixel. In this case the RLE data should be read into an array
of chars. To expand data, the low order seven bits of the first byte: bits[6..0] are used to form a
count. If the high order bit of the first byte is 1: bit[7], then the count is used to specify how many
bytes to copy from the RLE data buffer to the destination. Otherwise, if the high order bit of the
first byte is 0: bit[7], then the count is used to specify how many times to repeat the value of the
following byte, in the destination. This process continues until a count of 0 is found. This should
decompress exactly XSIZE pixels. 

Here is example code to decompress a scanline: 

            expandrow(optr,iptr,z)
            unsigned char *optr, *iptr;
            int z;
            {
                unsigned char pixel, count;
            
                optr += z;
                while(1) {
                    pixel = *iptr++;
                    if ( !(count = (pixel & 0x7f)) )
                        return;
                    if(pixel & 0x80) {
                        while(count--) {
                            *optr = *iptr++;
                            optr+=4;
                        }
                    } else {
                        pixel = *iptr++;
                        while(count--) {
                            *optr = pixel;
                            optr+=4;
                        }
                    }
                }
            }

If BPC is 2, there is one short (2 bytes) per pixel. In this case the RLE data should be read into an
array of shorts. To expand data, the low order seven bits of the first short: bits[6..0] are used to
form a count. If bit[7] of the first short is 1, then the count is used to specify how many shorts to
copy from the RLE data buffer to the destination. Otherwise, if bit[7] of the first short is 0, then
the count is used to specify how many times to repeat the value of the following short, in the
destination. This process proceeds until a count of 0 is found. This should decompress exactly
XSIZE pixels. Note that the byte order of short data in on the input file should be observed, as
described above. 

Implementation notes

Implementation of both RLE and VERBATIM format for images with BPC of 1 is required since
the great majority of SGI images are in this format. Support for images with a 2 BPC is
encouraged. 

If the ZSIZE of an image is 1, it is assumed to represent B/W values. If the ZSIZE is 3, it is
assumed to represent RGB data, and if ZSIZE is 4, it is assumed to contain RGB data with alpha. 

Naming Conventions

On SGI systems, SGI image files end with the extension .bw if they are B/W images, they end in
.rgb if they contain RGB image data, and end in .rgba if they are RGB images with alpha channel. 

Sometimes the .sgi extension is used as well. 

An example: This program will write out a valid B/W SGI image file: 

    #include "stdio.h"

    #define IXSIZE      (23)
    #define IYSIZE      (15)

    putbyte(outf,val)
    FILE *outf;
    unsigned char val;
    {
        unsigned char buf[1];

        buf[0] = val;
        fwrite(buf,1,1,outf);
    }

    putshort(outf,val)
    FILE *outf;
    unsigned short val;
    {
        unsigned char buf[2];

        buf[0] = (val>>8);
        buf[1] = (val>>0);
        fwrite(buf,2,1,outf);
    }

    static int putlong(outf,val)
    FILE *outf;
    unsigned long val;
    {
        unsigned char buf[4];

        buf[0] = (val>>24);
        buf[1] = (val>>16);
        buf[2] = (val>>8);
        buf[3] = (val>>0);
        return fwrite(buf,4,1,outf);
    }

    main()
    {
        FILE *of;
        char iname[80];
        unsigned char outbuf[IXSIZE];
        int i, x, y;

        of = fopen("example.rgb","w");
        if(!of) {
            fprintf(stderr,"sgiimage: can't open output file\n");
            exit(1);
        }
        putshort(of,474);       /* MAGIC                */
        putbyte(of,0);          /* STORAGE is VERBATIM  */
        putbyte(of,1);          /* BPC is 1             */
        putshort(of,2);         /* DIMENSION is 2       */
        putshort(of,IXSIZE);    /* XSIZE                */
        putshort(of,IYSIZE);    /* YSIZE                */
        putshort(of,1);         /* ZSIZE                */
        putlong(of,0);          /* PIXMIN is 0          */
        putlong(of,255);        /* PIXMAX is 255        */
        for(i=0; i<4; i++)      /* DUMMY 4 bytes        */
            putbyte(of,0);
        strcpy(iname,"No Name");
        fwrite(iname,80,1,of);  /* IMAGENAME            */
        putlong(of,0);          /* COLORMAP is 0        */
        for(i=0; i<404; i++)    /* DUMMY 404 bytes      */
            putbyte(of,0);

        for(y=0; y < IYSIZE; y++) {
            for(x=0; x < IXSIZE; x++) 
                outbuf[x] = (255*x)/(IXSIZE-1);
            fwrite(outbuf,IXSIZE,1,of);
        }
        fclose(of);
    }

========================================================================

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 May  5 18:14:48 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id SAA01850 for info-performer-dist@holodeck.engr.sgi.com; Tue, 5 May 1998 18:10: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 SAA01796 for <info-performer@holodeck.engr.sgi.com>; Tue, 5 May 1998 18:10: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 EAA19643353
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 5 May 1998 04:59:18 -0700 (PDT)
Received: from relay4.smtp.psi.net (relay4.smtp.psi.net [38.9.52.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id EAA27678
	for <info-performer@sgi.com>; Tue, 5 May 1998 04:59:17 -0700 (PDT)
	mail_from (gwaldron@peril.com)
Received: from [38.181.237.15] (helo=killer)
	by relay4.smtp.psi.net with smtp (Exim 1.90 #1)
	id 0yWgNL-0006rS-00; Tue, 5 May 1998 07:59:12 -0400
Message-ID: <003601bd781d$dfced220$0fedb526@killer.potomacinstitute.com>
From: "Glenn Waldron" <gwaldron@peril.com>
To: <info-performer@sgi.com>, "ken sartor" <sartor@visidyne.com>
Subject: Re: rgba file formats
Date: Tue, 5 May 1998 08:03:50 -0400
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

Ken-
Someone already gave you a pointer to the Haeberli page, so here's
some code to look at.. it's an rgb/rgba/bw loader I wrote a while
back, using the Haeberli page as a reference.  Feel free to use it.
enjoy- glenn.

--
Glenn Waldron, Peril Technologies * gwaldron@peril.com 703.598.7835

-----Original Message-----
From: ken sartor <sartor@visidyne.com>
To: info-performer@sgi.com <info-performer@sgi.com>
Date: Monday, May 04, 1998 6:44 PM
Subject: rgba file formats


>
>Hi -
>
>I realize this is a bit off topic but...
>
>Does anyone know the exact format of a RGBA file?  By this
>i mean both what ancillary information is written (e.g.,
>interleaved, sequential, separate) and how the RGBA values
>are written (e.g., 0-255, 0-1.0, other). 
>
>A code snippet or a pointer to useful docs would be greatly 
>appreciated!!!
>
>ken
>=======================================================================
>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 May  5 18:14:50 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id SAA01790 for info-performer-dist@holodeck.engr.sgi.com; Tue, 5 May 1998 18:10: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 SAA01758 for <info-performer@holodeck.engr.sgi.com>; Tue, 5 May 1998 18:10: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 EAA19424936
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 5 May 1998 04:53:40 -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 EAA26826
	for <info-performer@sgi.com>; Tue, 5 May 1998 04:53:38 -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 AAA13616
          for <info-performer@sgi.com>; Tue, 5 May 1998 07:52:10 -0400
Message-ID: <354EFDC5.6253FEDA@bah.com>
Date: Tue, 05 May 1998 07:53:41 -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: sharper image
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Good morning pfpeople;

I'm need to map a sharp detailed texture onto a terrain that will be
used for a slow

moving vehicle.  The desert texture is detailed enough to convince a
flight simulator

crew,but not the low level folks. the closer to the ground the fuzzer it
gets. if I map

it smaller (more texels that polys) it produces a "tiled" effect.  the
textured was scanned

and scaled.  I've tried differnt filters w/o any luck. If  I'm missing a
procedure please

enlighten...my clock is running!! GULP!

thanks

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  Tue May  5 18:14:50 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id SAA01924 for info-performer-dist@holodeck.engr.sgi.com; Tue, 5 May 1998 18:10: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 SAA01896 for <info-performer@holodeck.engr.sgi.com>; Tue, 5 May 1998 18:10: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 DAA19045052
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 5 May 1998 03:09:02 -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 DAA07669
	for <info-performer@sgi.com>; Tue, 5 May 1998 03:08:56 -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 SAA21421 for <info-performer@sgi.com>; Tue, 5 May 1998 18:08:53 +0800 (SGT)
Received: from liuxy.nsrc.nus.sg(137.132.15.179) by aba.nsrc.nus.sg via smap (V1.3)
	id sma021410; Tue May  5 18:08:24 1998
Message-ID: <354EE54C.4FB6@nsrc.nus.edu.sg>
Date: Tue, 05 May 1998 18:09: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: Repost: uncalled pre-isect callback
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 7bit
Status: O

Hi, all, please help me identify this headache problem:

In order to implement bounding box to bounding box collision 
detection, my approach is by using a dummy vector to activate 
the ISECT process, which in turn will activate the pre-isect callback
attached to each node. In this callback, "pfBox.contains ..."
is called to detect the collison between boxes. The infomation
for the object that is moving(like bbox, position etc.) are
stored in shared memory, this particular node is disabled for
ISECT.

What happens is that sometimes the pre-isect functions
is called , sometimes not and then called again. The "printf"
before the isect do print sth and ISECT masks are just correct. 
It seems there are some magic area the ISECT process is dead.

*****************************************************
The code looks like:

group->setTravFuncs(PFTRAV_ISECT, box2boxHit, NULL);
group->setTravFuncs(PFTRAV_APP, printInfo, NULL);
group->setTravData(PFTRAV_ISECT, (void *)shared_ptr);

int printInfo(....)
{ print out ISECT mask value == 0xffff;
  return PFTRAV_CONT;
}

int box2boxHit(pfTraverser *trav, void *data)
{  
  pfNode *node = trav->getNode();
  
  printf("\n in Call back");           // doesn't come out every time  
  if (box1.contains(&box2) != PFIS_FALSE) 
     printf("\n *************************MAY HIT");

  return PFTRAV_CONT;
}

 // collision detection between objects, use a dummy line
 // to initiate ISEC traversal, actual detection done in
 // each node's pre-isect Callback.
 
  pfSegSet segset;
  pfHit **hits[32];
  segset.mode = PFTRAV_IS_GSET;
  segset.userData     = (void *)NULL;
  segset.activeMask   = 1;
  segset.isectMask    = 0xffff;      
  segset.bound        = (void *)NULL;
  segset.discFunc     = NULL;
  segset.segs[0].dir.set(0.0f, 0.0f, 1.0f); // dummy vector
  segset.segs[0].length = 100.0f;
printf("\n begin   ");                      // always come out
  (shared_ptr->scene)->isect(&segset, hits);  // activate it
           
Thanks for any idea.

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  Tue May  5 18:14:52 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id SAA01381 for info-performer-dist@holodeck.engr.sgi.com; Tue, 5 May 1998 18:04: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 SAA01328 for <info-performer@holodeck.engr.sgi.com>; Tue, 5 May 1998 18:04: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 KAA19583014
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 5 May 1998 10:18: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 KAA14120
	for <info-performer@sgi.com>; Tue, 5 May 1998 10:18:53 -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 KAA20642668;
	Tue, 5 May 1998 10:18: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 KAA01675; Tue, 5 May 1998 10:18:25 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <354F49E1.F5272F62@sgi.com>
Date: Tue, 05 May 1998 10:18: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: 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
References: <199804271828.UAA17010@s00sn1.fel.tno.nl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Mario Veraart 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
> 
> 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?


The problem is the relative positions of the depth image and
projected r coordinate.

An offset is required to avoid what ammounts to resolution
dependent z fighting in the projected light space. Your offset
is grossly large. You should try a shadow map frustum with near
and far clip planes closer, and more zbuffer precision if you
have i and a smaller displacement in r on the texture matrix.

See www.dorbie.com for my projective depth map shadow
adventures in th 'UAV' section.

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 May  5 18:14:50 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id SAA01416 for info-performer-dist@holodeck.engr.sgi.com; Tue, 5 May 1998 18:04: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 SAA01382 for <info-performer@holodeck.engr.sgi.com>; Tue, 5 May 1998 18:04: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 KAA17731195
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 5 May 1998 10:11:08 -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 KAA10516
	for <info-performer@sgi.com>; Tue, 5 May 1998 10:11:07 -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 KAA20627943;
	Tue, 5 May 1998 10:11:06 -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 KAA01662; Tue, 5 May 1998 10:11:05 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <354F4828.2E05C6C8@sgi.com>
Date: Tue, 05 May 1998 10:11:04 -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.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

Rick Weyrauch wrote:
> 
> 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++'.

I think the point I was making is that this is already inevitable if you
proceed.

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 May  5 19:23:37 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id TAA04272 for info-performer-dist@holodeck.engr.sgi.com; Tue, 5 May 1998 19:08: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 TAA04245 for <info-performer@holodeck.engr.sgi.com>; Tue, 5 May 1998 19:08: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 TAA21032722
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 5 May 1998 19:08:54 -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 TAA05786
	for <info-performer@sgi.com>; Tue, 5 May 1998 19:08:53 -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 TAA20913141;
	Tue, 5 May 1998 19:08:52 -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 TAA02706; Tue, 5 May 1998 19:08:52 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <354FC634.C33B5F97@sgi.com>
Date: Tue, 05 May 1998 19:08:52 -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: Castillo Joe <castillo_joe@bah.com>
CC: "info-performer@sgi.com" <info-performer@sgi.com>
Subject: Re: sharper image
References: <354EFDC5.6253FEDA@bah.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Castillo Joe wrote:
> 
> Good morning pfpeople;
> 
> I'm need to map a sharp detailed texture onto a terrain that will be
> used for a slow
> 
> moving vehicle.  The desert texture is detailed enough to convince a
> flight simulator
> 
> crew,but not the low level folks. the closer to the ground the fuzzer it
> gets. if I map
> 
> it smaller (more texels that polys) it produces a "tiled" effect.  the
> textured was scanned
> 
> and scaled.  I've tried differnt filters w/o any luck. If  I'm missing a
> procedure please
> 
> enlighten...my clock is running!! GULP!
>

You have to eliminate the low frequency data from the detailed
texture image. Send me the detailed texture image and I'll take
a look at it.

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 May  6 00:15:17 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id XAA05134 for info-performer-dist@holodeck.engr.sgi.com; Tue, 5 May 1998 23:58: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 XAA05107 for <info-performer@holodeck.engr.sgi.com>; Tue, 5 May 1998 23:58: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 XAA20870662
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 5 May 1998 23:58:29 -0700 (PDT)
Received: from sunu450.rz.ruhr-uni-bochum.de (sunu450.rz.ruhr-uni-bochum.de [134.147.222.33]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id XAA07999
	for <info-performer@sgi.com>; Tue, 5 May 1998 23:58:23 -0700 (PDT)
	mail_from (bart@neurobiologie.ruhr-uni-bochum.de)
Received: (qmail 6775 invoked from network); 6 May 1998 06:58:16 -0000
Received: from sunflow.neurobiologie.ruhr-uni-bochum.de (134.147.236.150)
  by mailhost.rz.ruhr-uni-bochum.de with SMTP; 6 May 1998 06:58:16 -0000
Received: from truus (truus.neurobiologie.ruhr-uni-bochum.de) by sunflow.neurobiologie.ruhr-uni-bochum.de (4.1/SMI-4.1)
	id AA10452; Wed, 6 May 98 09:00:39 +0200
Received: by localhost with Microsoft MAPI; Wed, 6 May 1998 09:00:38 +0200
Message-Id: <01BD78CD.702CB990.bart@neurobiologie.ruhr-uni-bochum.de>
From: bart <bart@neurobiologie.ruhr-uni-bochum.de>
To: "'info-performer@sgi.com'" <info-performer@sgi.com>
Subject: Text , Strings and Fonts
Date: Wed, 6 May 1998 09:00:37 +0200
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Status: O

Hi Performers,

I am having difficulties getting to grips with pfText,pfString and pfFont.
I have managed to get some text on the screen, but changing the attributes
of this text seems near impossible. I searched through the list's archives 
but found
no solution to my problems.

Three, possibly related questions are (in decreasing order of importance 
for me):

1)  I tried using  pfStringColor to change the strings colour, but had no 
success. The strings stay black (visible on a white background), even 
though a pfGetStringColor tells me that the RGB values are properly set to 
(1 1 1) . Should I reinitialise the string somehow after changing its 
colour?

2) I scale the strings with pfStringMat etc. This works but it is a bit 
cumbersome. Is there no pfFontSize command?  I cannot find it inthe man 
pages.

3) ThreeD fonts look very nice, but in my application they are a bit 
superfluous and seem to put quite a load on my Indigo2. I just want a few 
lines of simple text : are there simpler fonts for this purpopse? (I tried 
using the FontManager and fmprstr() but that crashed the program).

Any help is much appreciated.
Regards,

Bart.

Bart Krekelberg, PhD
Dpt. Zoology and Neurobiology
Ruhr University Bochum
44780 Bochum
Germany
Tel: +49 (0)234 7004369
Fax: +49 (0)234 7094 278
Email: bart@neurobiologie.ruhr-uni-bochum.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 May  6 00:54:51 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id AAA05331 for info-performer-dist@holodeck.engr.sgi.com; Wed, 6 May 1998 00:34: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 AAA05304 for <info-performer@holodeck.engr.sgi.com>; Wed, 6 May 1998 00:34: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 AAA21054870
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 6 May 1998 00:34:46 -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 AAA15960
	for <info-performer@sgi.com>; Wed, 6 May 1998 00:34:42 -0700 (PDT)
	mail_from (abadia@sgonyx.ita.es)
Received: (from abadia@localhost)
	by sgonyx.ita.es (8.8.8/8.8.8) id JAA22685
	for info-performer@sgi.com; Wed, 6 May 1998 09:34:35 +0200 (DST)
From: "Javier Abadia Miranda" <abadia@sgonyx.ita.es>
Message-Id: <9805060934.ZM22683@pandora.ita.es>
Date: Wed, 6 May 1998 09:34:35 +0000
In-Reply-To: Jay Gischer <gischer@puget.engr.sgi.com>
        "Memory space in db loaders" (May  4,  2:34pm)
References: <9805041248.ZM14136@pandora.ita.es> 
	<199805042134.OAA45083@puget.engr.sgi.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: info-performer@sgi.com
Subject: Re: Memory space in db loaders
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O


Jay Gisher wrote:

>  > Otherwise, do they mantain the values from one call to
>  > the next?
>  >
> Yes.
> Well, there's one thing I don't know for sure, and that is if
> Performer ever unlinks a dynamically linked loader.  I don't think it
> does, but I haven't verified it, and if it does, then the answer is
> "No, sometimes they don't."
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~

That was exactly what my question was about. Can
someone tell me if loader's code gets ulinked and linked
each time, or what.


Thank you!


=======================================================================
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 May  6 01:26:56 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id BAA05477 for info-performer-dist@holodeck.engr.sgi.com; Wed, 6 May 1998 01:06: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 BAA05450 for <info-performer@holodeck.engr.sgi.com>; Wed, 6 May 1998 01:06: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 BAA20882617
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 6 May 1998 01:06:03 -0700 (PDT)
Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id BAA22904
	for <info-performer@sgi.com>; Wed, 6 May 1998 01:06:01 -0700 (PDT)
	mail_from (Francois.Sillion@imag.fr)
Received: from safran.imag.fr (safran.imag.fr [129.88.42.9])
	by imag.imag.fr (8.8.5/8.8.5) with ESMTP id KAA06771
	for <info-performer@sgi.com>; Wed, 6 May 1998 10:05:53 +0200 (MET DST)
Received: (from sillion@localhost) by safran.imag.fr (8.6.10/8.6.9) id KAA22463 for info-performer@sgi.com; Wed, 6 May 1998 10:05:52 +0200
From: Francois Sillion <Francois.Sillion@imag.fr>
Message-Id: <199805060805.KAA22463@safran.imag.fr>
Subject: Annoying warnings with pf2.2MR
To: info-performer@sgi.com
Date: Wed, 6 May 1998 10:05:52 +0200 (MDT)
In-Reply-To: <199805010900.CAA03358@holodeck.engr.sgi.com> from "info-performer Mailing List" at May 1, 98 02:00:01 am
Reply-To: Francois.Sillion@imag.fr
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Status: O


Dear Performers,

Ever since we upgraded to Performer 2.2MR, I am getting the following
Warning messages whenever I compile my program. Apparently this does not 
prevent my program to run normally, but I would like to
understand what's going on and avoid filling my screen with these
messages so I can see the real errors :-)

Would anybody have a clue as to what this means and what I am doing wrong?
Here is the link line fromthe Makefile and the messages from the linker:
Again, this worked fine with pf 2.1 aa well as a number of beta 2.2 versions.

Thanks a lot!

--- VilleOGL ---
Building version  N32
	 CC -n32 -mips4 Carte.o Couleur.o Critere.o Decor.o Hlist.o Impostor.o ImpostorMesh.o Menu.o Offscreen.o Parametres.o SingleEdgePartitioner.o SingleImpostorMesh.o TextureEXT.o ThreeLayerPartitioner.o appOptimal.o VilleMotifGui.o quadedge.o File.o CityFile.o Stack.o vmath.o quat.o random.o Triangle.o Point.o Edge.o Block.o Map.o City.o LoadCity.o MaterialDefs.o Database.o PerformerDatabase.o CylindricalImpostorMesh.o fastimg.o LinkedObjectsManager.o LinkedObjects.o ImpostorLocalModel.o ImpostorParams.o ImpostorCamera.o PerformerEngine.o VilleControl.o Globals.o PerformerWidget.ogl.o Pieton.ogl.o Ville.ogl.o -o VilleN32.OGL.2.2 -IPA -L/h/gingembre/imagis/sillion/src/Ville/Essai -L/h/gingembre/imagis/sillion/lib -L/h/gingembre/imagis/sillion/src/util -L/h/gingembre/imagis/ibr/lib  -L/usr/lib32/Performer/Debug  -L/usr/lib32/Performer/Debug/libpfdb  -L/usr/lib32  -L/usr/lib32 -lsaveN32 -limage  -lGLw  -lGLU -lGL -lXext  -lXt -lXmu -lX11 -lXm  -lm  -lXm  -lXmu  -lX11  -lm  -lC -w!
 off 515,608,658,799  -lpf_ogl  -lpfdu_ogl  -lpfui  -lpfutil_ogl
ld32: WARNING 85: definition of XSGIvcQueryVersion in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcQueryVideoScreenInfo in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcListVideoFormats in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcListVideoFormatsCombinations in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcListVideoFormatsInCombination in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcLoadVideoFormat in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcLoadVideoFormatCombination in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcDisableChannel in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcQueryChannelInfo in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcQueryMonitorName in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcSetOutputGain in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcSetOutputPedestal in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcSetOutputPhaseH in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcSetOutputPhaseSCH in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcSetOutputPhaseV in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcSetChannelGammaMap in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcSetOutputBlanking in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcQueryOutputGain in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcQueryOutputPedestal in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcQueryOutputPhaseH in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcQueryOutputPhaseSCH in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcQueryOutputPhaseV in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcQueryChannelGammaMap in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcQueryOutputBlanking in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcSetOutputSync in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcQueryOutputSync in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcSetScreenInputSyncSource in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcQueryScreenInputSyncSource in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcSetPlatformParameter in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcQueryPlatformParameter in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcQueryScreenGammaMaps in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcQueryGammaMap in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcStoreGammaColors8 in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcStoreGammaColors16 in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcQueryGammaColors in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcSelectInput in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcFreeVideoFormatInfo in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of matchWilde in /usr/lib32/Performer/Debug/libpf_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfdu_ogl.so.
ld32: WARNING 85: definition of XSGIvcQueryVersion in /usr/lib32/Performer/Debug/libpfdu_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfui.so.
ld32: WARNING 85: definition of XSGIvcQueryVideoScreenInfo in /usr/lib32/Performer/Debug/libpfdu_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfui.so.
ld32: WARNING 85: definition of XSGIvcListVideoFormats in /usr/lib32/Performer/Debug/libpfdu_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfui.so.
ld32: WARNING 85: definition of XSGIvcListVideoFormatsCombinations in /usr/lib32/Performer/Debug/libpfdu_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfui.so.
ld32: WARNING 85: definition of XSGIvcListVideoFormatsInCombination in /usr/lib32/Performer/Debug/libpfdu_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfui.so.
ld32: WARNING 85: definition of XSGIvcLoadVideoFormat in /usr/lib32/Performer/Debug/libpfdu_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfui.so.
ld32: WARNING 85: definition of XSGIvcLoadVideoFormatCombination in /usr/lib32/Performer/Debug/libpfdu_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfui.so.
ld32: WARNING 85: definition of XSGIvcDisableChannel in /usr/lib32/Performer/Debug/libpfdu_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfui.so.
ld32: WARNING 85: definition of XSGIvcQueryChannelInfo in /usr/lib32/Performer/Debug/libpfdu_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfui.so.
ld32: WARNING 85: definition of XSGIvcQueryMonitorName in /usr/lib32/Performer/Debug/libpfdu_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfui.so.
ld32: WARNING 85: definition of XSGIvcSetOutputGain in /usr/lib32/Performer/Debug/libpfdu_ogl.so preempts that definition in /usr/lib32/Performer/Debug/libpfui.so.
ld32: Giving up after printing 50 warnings.  Use -wall to print all warnings.

+------------------+------------------------------------------------------+
| Francois SILLION | iMAGIS - GRAVIR/IMAG, B.P. 53, 38041 Grenoble Cedex 9|
|     '            | France. Tel:+33 4 76 51 43 54 - Fax:+33 4 76 63 55 80|
+------------------+--------+---------------------------------------------+
| Francois.Sillion@imag.fr  | http://www-imagis.imag.fr/~Francois.Sillion |
+---------------------------+---------------------------------------------+
=======================================================================
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 May  6 03:10:59 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id CAA05857 for info-performer-dist@holodeck.engr.sgi.com; Wed, 6 May 1998 02:47: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 CAA05829 for <info-performer@holodeck.engr.sgi.com>; Wed, 6 May 1998 02: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 CAA20717449
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 6 May 1998 02:47:14 -0700 (PDT)
Received: from 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 CAA12469
	for <info-performer@sgi.com>; Wed, 6 May 1998 02:46:41 -0700 (PDT)
	mail_from (liuxy@ihpc.nus.edu.sg)
Received: (from smap@localhost)
          by aba.ihpc.nus.edu.sg (8.8.5/8.8.4)
	  id RAA05542 for <info-performer@sgi.com>; Wed, 6 May 1998 17:45:28 +0800 (SGT)
Received: from liuxy.nsrc.nus.sg(137.132.15.179) by aba.nsrc.nus.sg via smap (V1.3)
	id sma005513; Wed May  6 17:45:03 1998
Message-ID: <35503154.5A9D@ihpc.nus.edu.sg>
Date: Wed, 06 May 1998 17:45:57 +0800
From: Liu Xiaoyan <liuxy@ihpc.nus.edu.sg>
Organization: Institute of High Performance Computing
X-Mailer: Mozilla 3.0 (Win95; I)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: uncalled pre-isect callback: solved.
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 7bit
Status: O

Thanks, Jeremy, it works now. 

>From:  jaf@chem.ucsd.edu (Jeremy Friesner)
>Organization:  Entropiphilic Reorganization Consultants
> To:   Liu Xiaoyan <liuxy@ihpc.nus.edu.sg>

>Hmm, you might want to review the Performer manuals again, especially
>the parts where they talk about scene graph traversal.  They don't
>say too much about the ISECT traversal, but look at the part on the 
>CULL traversal (where they show the pictures of the toy airplane/teddy bear/etc)
>.  The ISECT traversal works much the same way;  that is, the traverser
>doesn't always test every node in the tree; rather, it will try to
>prune its traversal at every node if it can determine that collisions
>with children of that node are impossible.  So your
>box2boxHit function only gets called when the dummy vector in your
>segset is within the bounding area of the node's parent.

>The next thing I would try, then, is to set your dummy vector
>to take up part of the space your testing box is in.  (Maybe
>have it run from one corner of box1 to the other)

> It looks like:
> 
> group->setTravFuncs(PFTRAV_ISECT, box2boxHit, NULL);
> group->setTravData(PFTRAV_ISECT, (void *)shared_ptr);
> 
> int box2boxHit(pfTraverser *trav, void *data)
> {  
>   pfNode *node = trav->getNode();
>   printf("  ... info.... ");                // sometimes not printed
>   if (box1.contains(&box2) != PFIS_FALSE) 
>           printf("\n *************************MAY HIT");>  
>  // collision detection between objects, use a dummy line
>  // to initiate ISEC traversal, actual detection done in
>  // each node's isecCallback.
>           pfSegSet segset;
>            pfHit **hits[32];
>            segset.mode = PFTRAV_IS_GSET;
>            segset.userData     = (void *)NULL;
>            segset.activeMask   = 1;
>            segset.isectMask    = 0xffffffff;      
>            segset.bound        = (void *)NULL;
>            segset.discFunc     = NULL;
>            segset.segs[0].dir.set(0.0f, 0.0f, -1.0f); // dummy vector
>            segset.segs[0].length = 1.0f;
>    printf("\n .......   begin .......");              // always printed
>            (shared_ptr->scene)->isect(&segset, hits);  // activate it
>            
> 

***********************************************************************
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  Wed May  6 06:00:45 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id FAA06168 for info-performer-dist@holodeck.engr.sgi.com; Wed, 6 May 1998 05:33: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 FAA06141 for <info-performer@holodeck.engr.sgi.com>; Wed, 6 May 1998 05:33: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 FAA20883566
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 6 May 1998 05:33:03 -0700 (PDT)
Received: from gatekeep.marconi.ca (gatekeep.marconi.ca [198.168.197.34]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id FAA14757
	for <info-Performer@sgi.com>; Wed, 6 May 1998 05:32:57 -0700 (PDT)
	mail_from (gamblem@kan.marconi.ca)
Received: from av310a.mtl.marconi.ca by gatekeep.marconi.ca; (5.65/1.1.8.2/21Sep94-0917AM)
	id AA27070; Wed, 6 May 1998 08:32:52 -0400
Received: from kan.marconi.ca (dagwood.kan.marconi.ca)
 by av310a.mtl.marconi.ca (PMDF V5.1-8 #28207)
 with SMTP id <01IWPGHDJVIO0024VC@av310a.mtl.marconi.ca> for
 info-Performer@sgi.com; Wed, 6 May 1998 08:32:25 EDT
Received: from avgate.kan.marconi.ca by kan.marconi.ca (5.x/SMI-4.1)
 id AA12607; Wed, 06 May 1998 08:30:36 -0400
Received: by avgate.kan.marconi.ca with Microsoft Mail id
 <3550835E@avgate.kan.marconi.ca>; Wed, 06 May 1998 08:35:58 -0700 (PDT)
Date: Wed, 06 May 1998 07:30:00 -0700 (PDT)
From: "Gamble, Murray - Kan AV" <gamblem@kan.marconi.ca>
Subject: Missile Trails
To: SGI Performer Info <info-Performer@sgi.com>
Message-Id: <3550835E@avgate.kan.marconi.ca>
X-Mailer: Microsoft Mail V3.0
Encoding: 16 TEXT
Status: O


Hi all,

Would anyone be kind enough to provide a block of code illustrating how to 
correctly setup pfuSmoke to produce missile trails?  I have been trying on 
and off now for a few weeks and have not had any luck.  After setting the 
basic parameters and starting the smoke, I simply see no visual results.  It 
looks pretty straight forward, but a kick start from knowledgeable minds 
would be most appreciated.

Thank you,

Murray G. Gamble
Human Factors Engineering - Aerospace
Canadian Marconi Company
Kanata, Ontario, CANADA 
=======================================================================
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 May  6 06:20:58 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id FAA06224 for info-performer-dist@holodeck.engr.sgi.com; Wed, 6 May 1998 05:54: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 FAA06197 for <info-performer@holodeck.engr.sgi.com>; Wed, 6 May 1998 05:54: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 FAA18730768
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 6 May 1998 05:54: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 FAA20195
	for <info-performer@sgi.com>; Wed, 6 May 1998 05:54: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 HAA16131; Wed, 6 May 1998 07:53:39 -0500 (CDT)
Date: Wed, 6 May 1998 07:52:29 -0500 (CDT)
From: Steve Baker <sbaker@link.com>
X-Sender: steve@sutcliffe.bgm.link.com
Reply-To: Steve Baker <sbaker@link.com>
To: Castillo Joe <castillo_joe@bah.com>
cc: "info-performer@sgi.com" <info-performer@sgi.com>
Subject: Re: sharper image
In-Reply-To: <354F50FA.BDF4FB00@bah.com>
Message-ID: <Pine.SGI.3.96.980506074847.26942D-100000@sutcliffe.bgm.link.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

On Tue, 5 May 1998, Castillo Joe wrote:

> I'm need to map a sharp detailed texture onto a terrain that will be used for a slow
> moving vehicle.  The desert texture is detailed enough to convince a flight simulator
> crew,but not the low level folks. the closer to the ground the fuzzer it
> gets. if I map it smaller (more texels that polys) it produces a "tiled" effect(ie. you
> could see the edges of the scanned image)

>   I've tried different filters w/o any luck. If  I'm missing a
> procedure please

The problem is that as you make the texels smaller, you make the entire map smaller
too - and the repitition of the map becomes more obvious. Your problem isn't
to do with filtering.

What you need to do is to build a much larger map. Don't just stretch the
existing map - that would make it go fuzzy (or blocky or something) again - and
don't just put (say) 16 copies of the existing map into the bigger one.

You need a map with more information in it.

As an alternative, you might want to consider going back to the original map
scale and adding detail texture (assuming you have a machine that can do
detail texture that is).

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 May  6 09:13:31 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id IAA07026 for info-performer-dist@holodeck.engr.sgi.com; Wed, 6 May 1998 08:56: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 IAA06999 for <info-performer@holodeck.engr.sgi.com>; Wed, 6 May 1998 08:56: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 IAA21095888
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 6 May 1998 08:55:56 -0700 (PDT)
Received: from mailgw1a.lmco.com (mailgw1a.lmco.com [192.31.106.7]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id IAA26856
	for <info-performer@sgi.com>; Wed, 6 May 1998 08:55:54 -0700 (PDT)
	mail_from (Mark.A.Wilson@lmco.com)
Received: from emss02g01.ems.lmco.com (emss02g01.ems.lmco.com [198.7.15.39])
	by mailgw1a.lmco.com (8.8.8/8.8.8) with ESMTP id JAA16236
	for <info-performer@sgi.com>; Wed, 6 May 1998 09:55:53 -0600 (MDT)
Received: from phad.ems.lmco.com ([160.205.32.46])
 by lmco.com (PMDF V5.1-10 #20543) with ESMTP id <0ESJ00IO8KQKW5@lmco.com> for
 info-performer@sgi.com; Wed,  6 May 1998 09:55:53 -0600 (MDT)
Received: from mailhub-gw.ems.lmco.com by phad.ems.lmco.com
 (X.400 to RFC822 Gateway); Wed, 06 May 1998 09:55:52 -0600
X400-Received: by mta lmagMTA in /c=us/admd=telemail/prmd=lmco/; Relayed; Wed,
 06 May 1998 09:55:50 -0600
X400-Received: by /c=us/admd=telemail/prmd=lmco/; Relayed; Wed,
 06 May 1998 09:55:50 -0600
Alternate-recipient: Allowed
Disclose-recipients: Prohibited
Content-return: Allowed
Date: Wed, 06 May 1998 09:55:50 -0600
From: Mark A Wilson <Mark.A.Wilson@lmco.com>
Subject: Re[2]: sharper image
To: castillo_joe@bah.com (IPM Return requested),
        sbaker@link.com (IPM Return requested)
Cc: info-performer@sgi.com (IPM Return requested)
Message-id: 
 <04FB335508806350*/c=us/admd=telemail/prmd=lmco/o=ems/ou=ccmail/s=Wilson/g=Mark/i=A/@MHS>
Content-identifier: 04FB335508806350
Conversion: Allowed
Original-encoded-information-types: IA5-Text
X400-Content-type: P2-1988 ( 22 )
X400-MTS-identifier: [/c=us/admd=telemail/prmd=lmco/; 04FB335508806350-lmagMTA]
X400-Originator: Mark.A.Wilson@lmco.com
X400-Recipients: non-disclosure;
Status: O


     Alternatively, you can reduce the contrast on the existing textures or 
     add noise for pseudo-detail.


______________________________ Reply Separator _________________________________
Subject: Re: sharper image
Author:  sbaker@link.com at MAILHUB-SMTP
Date:    5/6/98 7:33 AM


-- see attachments --
=======================================================================
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 May  6 10:10:02 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA07258 for info-performer-dist@holodeck.engr.sgi.com; Wed, 6 May 1998 09:55: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 JAA07231 for <info-performer@holodeck.engr.sgi.com>; Wed, 6 May 1998 09:55: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 JAA21195043
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 6 May 1998 09:55:27 -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 JAA21504
	for <info-performer@sgi.com>; Wed, 6 May 1998 09:55: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 JAA19152377;
	Wed, 6 May 1998 09:55: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 JAA03476; Wed, 6 May 1998 09:55:25 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <355095FD.6E5B93A3@sgi.com>
Date: Wed, 06 May 1998 09:55: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: bart <bart@neurobiologie.ruhr-uni-bochum.de>
CC: "'info-performer@sgi.com'" <info-performer@sgi.com>
Subject: Re: Text , Strings and Fonts
References: <01BD78CD.702CB990.bart@neurobiologie.ruhr-uni-bochum.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

bart wrote:
> 
> Hi Performers,
> 
> I am having difficulties getting to grips with pfText,pfString and pfFont.
> I have managed to get some text on the screen, but changing the attributes
> of this text seems near impossible. I searched through the list's archives
> but found
> no solution to my problems.
> 
> Three, possibly related questions are (in decreasing order of importance
> for me):
> 
> 1)  I tried using  pfStringColor to change the strings colour, but had no
> success. The strings stay black (visible on a white background), even
> though a pfGetStringColor tells me that the RGB values are properly set to
> (1 1 1) . Should I reinitialise the string somehow after changing its
> colour?
> 

This may be a state issue, perhaps you need to enable lighting
or some such thing for the string. Look at the setGstate method,
and check the material color mode, geometry color attributes may
be getting ignored.

> 2) I scale the strings with pfStringMat etc. This works but it is a bit
> cumbersome. Is there no pfFontSize command?  I cannot find it inthe man
> pages.
> 
> 3) ThreeD fonts look very nice, but in my application they are a bit
> superfluous and seem to put quite a load on my Indigo2. I just want a few
> lines of simple text : are there simpler fonts for this purpopse? (I tried
> using the FontManager and fmprstr() but that crashed the program).
> 

Look at pfdLoadFont, you have a large choice of styles most
of which eliminate the 3D stuff you probably currently use
PFDFONT_EXTRUDED. You can even use textured quads.

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 May  6 11:23:10 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA07608 for info-performer-dist@holodeck.engr.sgi.com; Wed, 6 May 1998 11:09: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 LAA07581 for <info-performer@holodeck.engr.sgi.com>; Wed, 6 May 1998 11:09: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 LAA20223498
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 6 May 1998 11:09:06 -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 LAA25591
	for <info-performer@sgi.com>; Wed, 6 May 1998 11:09:06 -0700 (PDT)
	mail_from (friedman@ucla.edu)
Received: from ucla.edu by aud.ucla.edu (SMI-8.6/SMI-SVR4)
	id LAA01943; Wed, 6 May 1998 11:09:55 -0700
Sender: scott@ucla.edu
Message-ID: <3550A6FE.48022C49@ucla.edu>
Date: Wed, 06 May 1998 11:07:58 -0700
From: "Scott A. Friedman" <friedman@ucla.edu>
X-Mailer: Mozilla 4.05 [en] (X11; U; IRIX64 6.2 IP28)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: Merging pfScene's
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Hi,

Situation:

Several scene graphs each rooted with a pfScene.  All scene graphs have
had pfdMakeSharedScene called on them and are saved as individual .pfb
files.

Some set of the .pfb files are loaded - each with there own pfScene.  Is
there now a way to merge the  scenes together - easily?

Attaching the scene graphs (minus their pfScenes) to a new pfScene and
repeating the pfdMakeSharedScene does not work.  My guess is that the
state that was extracted previously and placed in the original pfScene
nodes is now 'lost' from the point of view of the new pfScene.  (??)
For example, no textures show up.

Simply combining the GeoStates of the two original pfScene nodes
(manually or otherwise) dosn't appear to me to be the correct thing to
do - and probably wouldn't work anyway - or would it?

I know the maual says that you can only put a pfScene at the root and it
cannot be a child of any other nodes.  But it seems to me that something
in the spirit of a pfScene would be useful here.  Something like a group
that could set a new default state but not be a scene.  That would allow
me to pull out the GeoStates in the two existing pfScene and place them
into these new 'state setting' nodes.

Some advise on what might be the best way to acheive this would be nice
(read - easier).


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 May  6 11:23:11 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA07579 for info-performer-dist@holodeck.engr.sgi.com; Wed, 6 May 1998 11:08: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 LAA07552 for <info-performer@holodeck.engr.sgi.com>; Wed, 6 May 1998 11:08: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 LAA20222997
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 6 May 1998 11:08:19 -0700 (PDT)
Received: from remi.engr.sgi.com ([150.166.37.25]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id LAA25205
	for <info-performer@sgi.com>; Wed, 6 May 1998 11:08:18 -0700 (PDT)
	mail_from (remi@remi.engr.sgi.com)
Received: (from remi@localhost) by remi.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA03929; Wed, 6 May 1998 11:08:13 -0700
From: remi@remi.engr.sgi.com (Rémi Arnaud)
Message-Id: <199805061808.LAA03929@remi.engr.sgi.com>
Subject: Re: pfUpdatable::pf_addUpdate ??!
To: sbaker@link.com
Date: Wed, 6 May 1998 11:08:12 -0700 (PDT)
Cc: info-performer@sgi.com
In-Reply-To: <Pine.SGI.3.96.980501125859.1088A-100000@sutcliffe.bgm.link.com> from "Steve Baker" at May 1, 98 01:03:34 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

Steve Baker wrote:
> 
> 
> 
> I'm seeing this message coming out of Perf2.2 MR, can anyone
> translate it into English for me?
> 
> DEBUG pfUpdatable::pf_addUpdate not called from APP process=PID:16364 DBASE ,Updatable=pfGroup
> 
> ...sometimes it says 'pfLOD' instead of 'pfGroup'.
> 
> What is the function of this 'pf_addUpdate' function - and what might I be 
> calling that in turn is calling it?
> 
> I am paging data from disk in my DBASE process - and every now and again I'll
> get zillions of these messages.

 Every libpf object (pfGroup, pfLOD...) have multiple copies that each correspond of
 one of the APP/CULL/DRAW stage of the software pipeline. Performer synchronization
 mechanism works using the addUpdate mechanism which is hidden inside pf objects.

 This mechanism works only if called from the Application process, no other process
 can modify the scene graph without perturbating the synchronization mechanism, and
 that can be fatal. This problem was very difficult to track, so 2.2 has this 
 warning that let you know (in that particular case) that the DBASE process did a 
 direct modification to a pfGroup node. So it tells you that the mandatory pfBuffer
 mechanism was not used in the Dbase process, and that the scene graph may be
 corrupted.

 I hope this helps.

    _  /              _             _ 
   |_) _ ._ _ 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  Wed May  6 12:46:50 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA00942 for info-performer-dist@holodeck.engr.sgi.com; Wed, 6 May 1998 12:33: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 MAA00915 for <info-performer@holodeck.engr.sgi.com>; Wed, 6 May 1998 12:33: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 MAA21426154
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 6 May 1998 12:28:15 -0700 (PDT)
Received: from lorien.creol.ucf.edu (lorien.creol.ucf.edu [132.170.160.102]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id MAA27838
	for <info-performer@sgi.com>; Wed, 6 May 1998 12:28:10 -0700 (PDT)
	mail_from (baillot@lorien.creol.ucf.edu)
Received: from vision.creol.ucf.edu by lorien.creol.ucf.edu (5.x/SMI-SVR4)
	id AA11709; Wed, 6 May 1998 15:27:56 -0400
Date: Wed, 6 May 1998 15:27:50 -0400 (EDT)
From: Baillot Yohan <baillot@lorien.creol.ucf.edu>
To: info-performer@sgi.com
Subject: Texturing an inventor model, pretty urgent
Message-Id: <Pine.SGI.3.96.980506151819.19716A-100000@vision.creol.ucf.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

Hello,

I have a inventor model of a bone. I'd like to apply a texture on it from
a file in .rgb format. In the file in inventor format, there is texture
indexes that are specified but they are all at 0. I guess that means there
is no texture coordinates given in the file.

I'd like to know if there is a way to generate automatically texture
coordinates for my model like it is possible to do in OpenGL, and how.
Then I'd like to know how to apply the rgb texture from an external file
(external meaning it is not specified in the Inventor model) that I would
load and apply at the textures coordinates generated automatically.

I would appreciate if you could give me any comments, suggestions, pointer
or even source code at baillot@creol.ucf.edu.

Have a very good day

Yohan

 _______________________________________________________________________
 _______________________________________________________________________
		
 Yohan BAILLOT,
 Manager of the VGI Laboratory at CREOL,
 Graduate Student of the School of Computer Sciences at UCF.
 		
 Vision Graphics and Image Laboratory (VGI),
 Center for Research and Education in Optics and Lasers (CREOL),
 University of Central Florida (UCF),
 4000 Central Florida Boulevard,                 ______
 PO BOX 162700,                                 /\     \
 Orlando, FL 32816-2700,                       /  \     \
 USA.					      /    \_____\
                                              \    /     /
 Voice : (407) 823 6917                        \  /     /
 Fax   : (407) 823 6880	                        \/_____/
 E-mail: baillot@creol.ucf.edu
 HomeP : http://www.creol.ucf.edu/~baillot
_______________________________________________________________________
_______________________________________________________________________


=======================================================================
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 May  6 13:14:41 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA01224 for info-performer-dist@holodeck.engr.sgi.com; Wed, 6 May 1998 13:06: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 NAA01195 for <info-performer@holodeck.engr.sgi.com>; Wed, 6 May 1998 13: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 NAA19717649
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 6 May 1998 13:06:34 -0700 (PDT)
Received: from bach.videotron.net (bach.videotron.net [205.151.222.10]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id NAA12875
	for <info-performer@sgi.com>; Wed, 6 May 1998 13:06:30 -0700 (PDT)
	mail_from (martel@signifi.com)
Received: from moreau.Signifi.com (ppp011.131.mmtl.videotron.net [207.96.131.11]) by bach.videotron.net (8.8.5/8.8.2) with SMTP id QAA12466 for <info-performer@sgi.com>; Wed, 6 May 1998 16:06:27 -0400 (EDT)
Sender: martel@bach.videotron.net
Message-ID: <3550B4DE.41C6@signifi.com>
Date: Wed, 06 May 1998 15:07:10 -0400
From: Yves Martel <martel@signifi.com>
Organization: Signifi.gVR
X-Mailer: Mozilla 3.01SGoldC-SGI (X11; I; IRIX64 6.4 IP30)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: Re: Text , Strings and Fonts
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

> Hi Performers,

> I am having difficulties getting to grips with pfText,pfString and pfFont.
> I have managed to get some text on the screen, but changing the attributes
> of this text seems near impossible. I searched through the list's archives 
> but found no solution to my problems.

> Three, possibly related questions are (in decreasing order of importance 
> for me):

> 1)  I tried using  pfStringColor to change the strings colour, but had no 
> success. The strings stay black (visible on a white background), even 
> though a pfGetStringColor tells me that the RGB values are properly set to 
> (1 1 1) . Should I reinitialise the string somehow after changing its 
> colour?

I had the same problem until I disabled the shading:

	pfDisable( PFEN_LIGHTING ) ;

	... write text here ...

	pfEnable( PFEN_LIGHTING ) ;


> 2) I scale the strings with pfStringMat etc. This works but it is a bit 
> cumbersome. Is there no pfFontSize command?  I cannot find it in the man 
> pages.

in 2D text I use the font sizes in pfuMakeRasterXFont()...

> 3) ThreeD fonts look very nice, but in my application they are a bit 
> superfluous and seem to put quite a load on my Indigo2. I just want a few 
> lines of simple text : are there simpler fonts for this purpopse? (I tried 
> using the FontManager and fmprstr() but that crashed the program).

Here is a piece of code I am using to write centered strings with 2D
text
in a 3D geometry:


//
--------------------------------------------------------------------------
void	Text_Centered( pfChannel *channel, char *str, pfVec3 pos )
{
	// --- no shading ---
	pfDisable( PFEN_LIGHTING ) ;

	// --- prepare a X font (select the font with "xfontsel") ---
	static	int     height ;
	static	pfuXFont XFont ;
	if ( ! height ) {
	    pfuMakeRasterXFont( "-sgi-rock-*-*-*-*-15-*-*-*-*-*-*-*", &XFont )
;
	    // --- center char verticaly ---
	    // height = pfuGetXFontHeight( &XFont ) ;
	    height = XFont.info->ascent / 2.0f ;
	}
	pfuSetXFont( &XFont ) ;

	// --- compute a scale factor from pixel size to lenght at this depth
---
	// at pos[1] (y), the width (x) of half-screen is: tan(fov/2) * y
	// the pixel size of half-screen is: res_x/2
	float fov_h, fov_v ;
	int   res_x, res_y ;
	channel->getSize( &res_x, &res_y ) ;
	channel->getFOV( &fov_h, &fov_v ) ;
	float fact = ( pfTan( fov_h*0.5f ) * pos[1] ) / (res_x * 0.5f) ;


	// --- text color ---
	glColor3f( 1.0f, 1.0f, 1.0f ) ;

	float larg = pfuGetXFontWidth( &XFont, str ) / 2.0f ;
	pfuDrawStringPos( str, pos[0] - (larg*fact), 
			       pos[1], 
			       pos[2] - (height*fact) ) ;
 
	pfEnable( PFEN_LIGHTING ) ;
}


_______________________________________________________
Yves Martel			Signifi.gVR
mailto:Martel@signifi.com       417 St-pierre suite 208
Tel: (514) 288-1453             Montreal, QC, CANADA
Fax: (514) 288-4112             H2Y 2M4
=======================================================================
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 May  6 13:14:43 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA01139 for info-performer-dist@holodeck.engr.sgi.com; Wed, 6 May 1998 13:00: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 NAA01112 for <info-performer@holodeck.engr.sgi.com>; Wed, 6 May 1998 13:00: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 NAA21287353
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 6 May 1998 13:00:34 -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 NAA09922
	for <info-performer@sgi.com>; Wed, 6 May 1998 13:00:32 -0700 (PDT)
	mail_from (lelkins@zeus.lnk.com)
Received: by zeus.lnk.com (4.1/1.35)
	id AA09370; Wed, 6 May 98 16:00:27 EDT
From: lelkins@zeus.lnk.com (Les Elkins)
Message-Id: <9805062000.AA09370@zeus.lnk.com>
Subject: STL and Performer?
To: info-performer@sgi.com
Date: Wed, 6 May 1998 16:00:27 -0400 (EDT)
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Status: O

Hello,

Are there any issues involved in using the Standard Template
Library with Performer? I've spliced some code into Perfly
that declares a pretty simple vector<int> x, but dies at
runtime with the following unresolved symbols:

 4248:perfly: rld: Error: unresolvable symbol in perfly: 
__node_allocator_lock__45__default_alloc_template__pt__13_XCiL11XCiL10
 4248:perfly: rld: Error: unresolvable symbol in perfly: 
free_list__45__default_alloc_template__pt__13_XCiL11XCiL10

This happens first thing at run time. The function containing 
the vector isn't yet called, the mere existance of the vector
causes the problems. When I create a simple test program with 
a vector and compile using CC, things work fine. Is there some 
makefile/compiler voodo I need to change in the 'perfly' Makefile?

I'm using the 'perfly' Makefile, running with C++ 7.1, 
IRIX 6.4 on an Octane, and looks to be Performer 2.1. I'm
getting the same results compiling with PFSTYLE set to 
32, N32, and 64.

Any suggestions would be most appreciated...

-Les Elkins

lelkins@lnk.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 May  6 14:04:40 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA01669 for info-performer-dist@holodeck.engr.sgi.com; Wed, 6 May 1998 13:54: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 NAA01642 for <info-performer@holodeck.engr.sgi.com>; Wed, 6 May 1998 13:53: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 NAA21248402
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 6 May 1998 13:53:59 -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 NAA02576
	for <info-performer@sgi.com>; Wed, 6 May 1998 13:53:56 -0700 (PDT)
	mail_from (prakash@drawcomp.com)
Received: (from nobody@localhost)
	by amber.drawcomp.com (8.8.5/8.8.5) id QAA05616;
	Wed, 6 May 1998 16:40:25 -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 xma005610; Wed, 6 May 98 16:39:57 -0400
Sender: gpmahesh@drawcomp.com
Message-ID: <3550CA9D.EE9EE173@drawcomp.com>
Date: Wed, 06 May 1998 16:39:57 -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: Les Elkins <lelkins@zeus.lnk.com>
CC: info-performer@sgi.com
Subject: Re: STL and Performer?
References: <9805062000.AA09370@zeus.lnk.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

All you need to do is use -ptused option in the compile line. This makes
the template instantiations. For more details please read the man pages
on CC (especially -ptused).

Hope this helps.
-Prakash

> 
> Are there any issues involved in using the Standard Template
> Library with Performer? I've spliced some code into Perfly
> that declares a pretty simple vector<int> x, but dies at
> runtime with the following unresolved symbols:
> 
>  4248:perfly: rld: Error: unresolvable symbol in perfly:
> __node_allocator_lock__45__default_alloc_template__pt__13_XCiL11XCiL10
>  4248:perfly: rld: Error: unresolvable symbol in perfly:
> free_list__45__default_alloc_template__pt__13_XCiL11XCiL10
> 
> This happens first thing at run time. The function containing
> the vector isn't yet called, the mere existance of the vector
> causes the problems. When I create a simple test program with
> a vector and compile using CC, things work fine. Is there some
> makefile/compiler voodo I need to change in the 'perfly' Makefile?
> 
> I'm using the 'perfly' Makefile, running with C++ 7.1,
> IRIX 6.4 on an Octane, and looks to be Performer 2.1. I'm
> getting the same results compiling with PFSTYLE set to
> 32, N32, and 64.
> 


-- 
  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  Wed May  6 15:31:01 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA02293 for info-performer-dist@holodeck.engr.sgi.com; Wed, 6 May 1998 15:16: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 PAA02266 for <info-performer@holodeck.engr.sgi.com>; Wed, 6 May 1998 15:16: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 PAA18175233
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 6 May 1998 15:16:18 -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 PAA06849
	for <info-performer@sgi.com>; Wed, 6 May 1998 15:16: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 PAA16508 for <info-performer@sgi.com>; Wed, 6 May 1998 15:27:18 -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 WAA09071 for <@plateau.engr.multigen.com:info-performer@sgi.com>; Wed, 6 May 1998 22:17:28 GMT
Received: (from marcus@localhost) by logan.engr.multigen.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA02675 for info-performer@sgi.com; Wed, 6 May 1998 15:17:27 -0700
From: "Marcus Barnes" <marcus@multigen.com>
Message-Id: <9805061517.ZM2673@logan.engr.multigen.com>
Date: Wed, 6 May 1998 15:17:27 -0700
In-Reply-To: "Javier Abadia Miranda" <abadia@sgonyx.ita.es>
        "Re: Memory space in db loaders" (May  6,  9:34am)
References: <9805041248.ZM14136@pandora.ita.es> 
	<199805042134.OAA45083@puget.engr.sgi.com> 
	<9805060934.ZM22683@pandora.ita.es>
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: Memory space in db loaders
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On May 6,  9:34am, Javier Abadia Miranda wrote:
>Jay Gisher wrote:
>>  > Otherwise, do they mantain the values from one call to
>>  > the next?
>>
>> Yes.
>> Well, there's one thing I don't know for sure, and that is if
>> Performer ever unlinks a dynamically linked loader.  I don't think it
>> does, but I haven't verified it, and if it does, then the answer is
>> "No, sometimes they don't."
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>That was exactly what my question was about. Can
>someone tell me if loader's code gets ulinked and linked
>each time, or what.

It is possible that a loader DSO could be unlinked (dlclose()). perfly never
does for example. Your application could, but you must realize that there are
many constraints wrt run-time un/linking. The constraints involve pfType
registration, multiprocessing address space issues and for some loaders C++
vtable access.

For example, a loader cannot be unlinked if:

- it needs to init() some pfType's then pfdInitConverter() must be called prior
  to pfConfig(). This is because pfType objects include static data so the dso
  must be mapped to the same address space in all processes.

- it attaches pfNodeTravFuncs() to nodes in the scene graph, then it cannot be
  unlinked while those nodes exist. Similar for new derivations of pfNode,
where
  C++ member functions may be called. In general, any C++ vtable must be mapped
  to the same address in all processes that might invoke a member function on
an
  object of that class.

- it owns a reference count on an object, via pfRef(), because the
  pfdExitConverter() does not include delegation to a cleanup function (ie
  pfdExitConverter_iv(), etc.) wherein such objects could be unreferenced.

So even though the pfdConverter() API implies that loaders can be unlinked. In
practice they cannot be ...

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-4103       +
=======================================================================
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 May  6 18:52:48 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id SAA03143 for info-performer-dist@holodeck.engr.sgi.com; Wed, 6 May 1998 18:40: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 SAA03116 for <info-performer@holodeck.engr.sgi.com>; Wed, 6 May 1998 18:40: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 SAA21495641
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 6 May 1998 18:40:17 -0700 (PDT)
Received: from bjsales.beijing.sgi.com ([134.14.74.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id SAA13636
	for <info-performer@sgi.com>; Wed, 6 May 1998 18:39:40 -0700 (PDT)
	mail_from (eric@gold.beijing.sgi.com)
Received: from gold.beijing.sgi.com by bjsales.beijing.sgi.com via ESMTP (940816.SGI.8.6.9/930416.SGI)
	 id IAA15704; Thu, 7 May 1998 08:59:14 +0800
Received: (from eric@localhost) by gold.beijing.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA17872; Wed, 6 May 1998 18:28:23 -0700
Message-Id: <199805070128.SAA17872@gold.beijing.sgi.com>
From: "eric" <eric@gold.beijing.sgi.com>
To: Baillot Yohan <baillot@lorien.creol.ucf.edu>, info-performer@sgi.com
References: <9805061828.ZM17851@gold.beijing.sgi.com>
Date: Thu, 07 May 1998 01:28:23 +0000 (GMT)
Subject:  Re: Texturing an inventor model, pretty urgent (part 4 of 4)
Content-type: message/partial; id="1111.17858.894504482.gold"; number=4; total=4
MIME-Version: 1.0
Status: O

FRIXFgwOFRATAggMEBAZDwQEDRMDEAMOCwgCAwoGBgcGEhgeISEiIAcJCw0EBRETFA4RDgkL
EhgZHR0bICEjLC03NUJKXnmNoKGmrK63ure3u7m7sbe2ucPCx8XHzMvKy8bIwLzAuriwrrey
rq+usrCqrq21ta+ysLe7t6+vt7zD1MrQy9Hd09jX1trUy8XQ0cDJx8rLz8/Sy8DH0crLzM7P
y8jDyc3CyczM0srPytDQzM/Mz8vIycPLzsXJwsvJz8zHzczP0MfOy9bR0NfQ1NPT19Xc39nc
2d/l4+Lh5eTh4ODi4Nvf29no2d3h6Or////4/f/+/vj37/Dt6+7p7OLp5OXk4+Hc4uXq6+jr
7unn6ezp7ujo6ujo5OPo6+/r6vDv9Pfw7e7v7+nl6uzo6uPZ17lbXEwjIREGKiYtJik3Nzcg
Gi0nFw8TGB8fBAwcFBsIDh0WBwMPGAkVFQsECR0aBAoJHh4WGBMmIxImGBsTEhMIEAsHCgYP
AQQAAAEBBQcEBQEGBgQCBgAAAwYAAwIFAQADAwcEAAILEyAjHBwYEwYGCQkKDA0RDRYNFBkZ
FxgnIhsvHSU0KzItM0VUaIebpbCltLG/wLi8uL29srixvr7IysrHx8vNvsa6vbm2urS3sqys
srKqqKqos5+yqZ6uqrCxrLW1sra8x8bMzMrV0dnU0tbK1cfLy8PLw8fLxc/DxsfIxs3T0tHT
zMfJyMTGztPQz8zP1NLLz83P0dHOzMvJz8/Rx9DK09DKzcnT1s3OztXX0dnO29jT2c7c2Njn
4eLl5uzb5eTe59re09na1NvW0t3L2dv//v///vr3+vv67/Hr8O/s6uns5ubq4eLf5+fo6ujt
6+rq6Oro6vDu7uzs5uXy6Ovv8fjt7/Dx9u7w7OXs4Ojo7ezX0bhgYUUjDxUXHCAtNCwpJB8k
GxQYCxALCw0KBgYKBAABAAQGAAIHAwIAAAIFAAACBwYCCAYKDRUVFRISFhUQERAODgwJBQQD
AQEDAAAFAAoBAgcECAQABAIAAAAIABAAAAsACQAABRAqLjQiHSElFwsPJRoeCRQqLSQRFB4X
HikkHhscOCMgISZJKSE4bIaWnaOlrrC3sbq8tbu1srq4wL67v8HIxsvKw8bAubm5vbOyrq+z
ra6upquoq6yvqqqtt7W4t7W2ubvGy83Ly9PV1tjX3NvV09HW0s7MxM3Rz9LN08/P0tLZ2dHW
zM3Ly8vMz83S183S0tLV09LO09HKycbNzcbJysrHzM3F0cLHysPSycrSztTR1NDT2dPc2dfc
1t3f4eLc4OHe4N7f3Nvd1dnW2tjX4eH////8+Pj9+PTw8ezp6Ovq7OXp5uno4uTb5vHk6+Lr
5erp6+Xp5O/j6+Ln6eXs5u3u5vTl7+3m8Ovr5eTo3+jo6uba1LZpPi0cCBMSGRwmJSYfIx8V
DRAMDg4NCQ4GBAAFAwMAAgAAAAACBAgAAAEABAAACAQUBQoJDBEKER8PIAwWFBIUDh8IGBoX
GwgDIAMdEhINBBQbDBkRFwQRFBcDHQABBAgYFAsVHy4pKTEhJxkjHxsRFgoTJSEHAgUSGhMV
GSAVGx4fFh0SEw0WDQomY42Zm6SrsbK5t7+6t7W0ubO6w8bLw8rHxMnIxcPCwMK6ur61tLGw
q660p6yrsrOurLG3t7e5tre1u8HGyc7U0tLZ1+Lb0dnR3MvMz8PPys3JxNXNyMTJzcfRzc3O
xcTIx87JzMrN0MrUzNLNyc/Kzc3I0MHNz8nNxsTJytDR0NHO0tHR0M/T0dTT1NTX1tjU1tXa
2d7b4N/h4eHf4d7g29zd2dvW2t3d4+b////9/fn7+Pb18+7r6+rr6ubq5ujm4uLi5+fl6Ofq
7+zp7O/u7u/t6+3n6+zs8O/w7vHy8e/w8O/s7fDt7fHx7une1L+kPTAbLB0fMSM2LDkqIS4i
IB0XIxIjEhwcBiEeIwgKFiERHAsiJR4eECYCHCASGSYbIBwWHyQSIB0nERATJhwUEw8kDREE
EBQLBgQNAAABCAAECgsAAwIBBAAFAAAAAAABBAoVICUlJS4oGRkdIRYOChASCQIEAhAQEhwl
LyAlGQ0YGhwIEhkPFQ0zb4qdoKWtsra8vcW/vb+6vb+/xMXIycvOxcPFwMzFx8C7wba1sbC2
srGqqLCmrJ6srKOzrbCxsLm1tbu6y8LNyMbU0NPU19rV1tHPzsrIycjLztDTzsbNzNLR0tLO
ysvGxsPL0s7R0tHS0dLR09TQz9DP0M3M0c3Tz8vMz9PW08/PztTS09XW2trZ2dfa3Nfa293c
39/b5unm6ufn5uTo5N7c2uLa3t3Z5d/////8/v77+ff19+7u6enu7Ojs5O3q6eXm5uzo7OXw
7+7o6e/v7PTl6ubo7OXr7+7w6vHv9fbu6u3u7erq7PXm6efa1sWpby86HxMTJDkpMC42Pi8n
JCQaEBMKIA0LCgAACgkCAgEfAAAKAAIDAgEJCAMDBgANBAoODSEODgcRDQ0QEw0QCQ4FCg8K
BAMEAAAEAAAAAwQAAwoAFwAIAAAZAAQBAB0QGhsdRkAvIidGLS4zNjMxKxAKFhIQGCItNScv
NS0zIBgoHREXDx0FDRw+YIKYmp6oqqy6ube5sbSztru2wrS4ub3Av7jDtr66vri5ubyzr7S1
sLGmrq+pqKusrKywsbS1tbW6uLq+yc7SyM7V1NbU2NbX2dLRy8jGy8nHz8/T0snP1dTR1tXO
yc3IzMvN0tLX2c7X0NnX0trQz9HR1srPytTW2M7Q0tjN1cvLxcrRyNPY0NbV1dLS0NDd3tTi
19fa3eLh3t3e39bb2tzf3trZ2t/b4dz////+/vT79vj08O7q7+rl6eXw6ern5Ozj6+7o8efp
8Orq6O7s6+3n7erk4+Tu5/Dv6/Dq7PDg7ubu7eTt5O7s7Ofa2sqzijEUHgwVHx8oKiwtLSgh
GBMSCQ4SCQ4EBAQDAAgAFAwABAIaBQ0FAxMACQcAEgAQBgooFSUQFh8YLQkMKBwkDxQiIxsH
GikdIQwLGhkRAhIiFA0LAAYFFAoEEBAQEAoCGjtBR1JHQilCSENHQDIoHCQRHCElLystMCkz
MykcFg0NFBkMDgwLCQgrWoOUnaWmtLW2uLq3s7O1tbm4vMG+xMbAwr3Bx8THxsG/urq0sbWx
srKrrq2rq62trrG1sb+5tbm5wMC+z8zT1tfe29vZ2Nza19TR1MjLyszLzcvU0NHN0czX0s3M
yMvKyc7Jz8rV1s7UztjU1MvM08/LzsTRzs7MxdHL0c/Jz8vNz8nPzdPTz9PN19fU2NPb39ja
0tnd3eHf5ePi4eHl5eHi3t/f293g5ef////4+/X1+Pf08e3m5eXm6ujt6+fo5uLm7u3q7unx
7+3s7evv8O7t6+fp4efp7+3v6ezv8+7p6u3s7+jp7PDs6+bh3NW7m2YYJwwKHyQ0KS0+Ozgh
JTckLQcQJykOBAglHQwAGBwmGQgcFBodDw0cEA0RByscHhsSFBQkKAoUBxkeBggJFw4OBQoS
DAMCAAUDAAIFAgACAgIAAQICAwQBAwEAAAQRHStJXW1hUTpAXlxZU1NILxQSFxUkJDM7RUlF
QykXDg8MCRQHAQ4GCgMdXICXm6OnsrC6vbq3ubm/t7vEwcTEyMbFw7vDusjLxsfBu7/At7Wx
trKorKmqsairrKOxsLCytLq2tLy2yMjYz8fL0tvUz9bK2tDMzcHPyMjKxdXK0c3X0M3T0MzR
xc3I0NHLz9XO1NTT2djX18vN09XT1tLN0tHR09HP1NXOzs3U0tPQzdPZz9bT3dzT2tTd2tLf
19zf3OXe4N7j6N7i2uPg3NzZ397Z2d7///////v5+/j38fDu7Orp7u7x7+ro7Ojs7urw8/Pu
8vDu7vDv9vLv7erv7+717/Dv8fXq7u7p9Ons7Onv5e3n6ObY2tDEqHYrJRgcEBQeLy0sMSMp
GRQRDBYMEAwIBgMEAAIBAAQCAwoLCgYCAAABBAAGAwMHBAsOEwkOEBAPCAkDCQMCBgMHBQEG
AAIDAAAAAAIAAAIEBAAAAwABAAEPAxMIBxMXMlFhanJ9d2hUbnZ1bmdeTUEkHR4fKS0/VWdg
TkciHhkdIhgZDRclGhgmY4acoaWoubS5urm6tb64tbS0w73AwsbIxcPCvsa+w8G5wLK7trG2
rqqtqrGorauxrqmvsLG5t7q6u73Ax87R1dPT1dvY3tvW187UzcjJydLUzdHU3NbT1djZ1tDQ
0NbRz83Q3eDX1dLU0tfW09TR1dXR1M3U19LR0tnSzs/Q183Iy8vVzdDQ0tbN1dXT29Pc29Tc
197d2uLc4ePc4N7k3NvX2N3b29zZ3uH////19fv/9/Hv7e3l5ebm7OTs5Obn4evk7/Dl7uLu
6Onw5+3t6PDp7eLk6OLu6+zp5Orf7vHq7ezt6err5u3e5uLd2c3IqXYoDBUXFSMjJCQfJh8j
GxgZDwYNDAcFAwQAAAAAAAAGAwkGBgMAAAAAAAcAAAMHAAAKCxEKCRAJDwgECAAMAgQAAAgF
FAQADgAaBQYWCQwHBhgNDAAGFBIADgMIDxo1Q2Vve4l/g3h5d4eCeIB6XkwxKh4eGStBYWtl
UVAgFhUVDwwKBRIHBggPT3WMn6SorKy5s7m6r724vb+6wcTDwcPIwsvFvcPHy8S+urq8vLa4
sK60rKywsq6yrKu1t7e3u726vb/CzsrU2Nfb29vW19nT3dLP08zUzM/Qz9vZ0MzV2dDQzdDU
ysnJ08/P08nV2tTYzdPNz9TTy87P18rTy9PWy9PRzdXK0MnMzcfOy87P0NPO2NjU2NHY29bd
2N/a3+Hh4uXj4+Ph5efk3+Dd4OHX4OP////5+vH39/Xv7uzn6uTq6OXr5+nm4+bl7+3r7urr
6+nr7O7t7O3r5+np5uno6+vr6unm7ufr6ero6+bs7evt6eTh29DDp3sbGQ8WKCAmJSo1KiIf
HCMSFgwRDwsbDxcQDQ0EFgwRFgsfGxgdBCgGDxsXGBUVKiIYChkeIB8uKhQTHR4PBQkgGhIA
ERQZCwAPCw0DBgAACwEADwUHBAIHCgMIEx0xRmt4iJGLioKGhIGPhIWCe3FaSzMoKDlTcIJ3
bllAFR4jFBgHCw0JHg0aYYOfnaaus7y6usTBvsDBxsXCw8jT0MzSysPEwMTIzcbByL2+urq3
q7Cvr7iqrqi0tKeysrO2qry1t7a1xcTSzMjVy9rX1NzT1czV2MrJxcvNz9TR2c/T2dXXztLU
yc/Oz9TN09LY1NPY0dLRz9TQ0tLQ09HV1dDSzc7Rz9HW1tjS1dXW19XV2NjY2tbV3dnY2tjc
297c3uHi4uPi4eLp4uPf3+Pi3uDl6uf////5+/349fTr8ubm4eLp5uvq5+fh5OLv6e7v7+fq
6OXn5+vs6e/o6url6eXt7ezr6erp6+vk6/Dt7vHs8fLu6uPa5NjRtoouJxscLj4+MjcrPjUy
MyYuIhMTIhUMBw8LDRQAFAMLBAkQEgoLCgMIGAUGAQIABwARBAgKCAMFCQwICAgQCgkBAAsI
AwgAEgEGAAAAAAAAAAgAEAAHAAMFAAITDRwmVHyOoJ6YlI6UkZOPlJiWko2AgXZlZHCDlo+U
dXxlPh8oKB0dDxYbGxMeT32Npq+osKy8t7a4sr+6vLy2xby6xb7CwMS/t8PCycDCvru9ubW2
qLKqsLOus6mvs6uyrLW6tLa6vr25xMjTztjY2dnX0dnV19HW0szJzsvL0NLW0tDa1drV0s7O
0dLL1tDO09Lb3NbZztfRzdbO09PM2szSy9HU08vOz9nHztDR1czRzNfV1dbS1dPR2M3d3dPb
1dbY2+La4eDc5d7b3uPi3N7Y2eDV2dr//v/+/vX7/fz39uvv7enn7e7z6uns6vLs7+/m8evp
5+Hq4ufk5eXa5uHa4OLo3eTj3OLW3+He6+Hn5+Lt4uzm6uXW29bItHwgHyIQIyAvLC4sMicl
JRYYFRARDQoLBwgJAggAAgEBCAsQBgYGAgkAAAACCgAIAAUZCxUIChAHHQIGGgkhAwkXEg8Z
CR0cEQEHFxgDAQohEwQACREMCg0VJxcXISczXY+dpK2mpJqZmZmblqCejpmLkoqFkImepZ6j
lJBzYUQiHRgUDw0JBwkISneQnaSir6q1uLW5u8LAv768wMTEyMPBw8bDxMPLzMjGwL+/vrqv
s7W0ta+ysK+vqrCusra0tLi5vL+5yM/V19Xc2N3f2t/c2dfY1s3RztLU1dTb3NvS19bc1dLO
09TT0dTJ0c/X19DV0dbTzM/O1dHJz8fX1MvSzNTRz87Mz9DOzcbP0NTV0dTS1dbO19LV1tPZ
19Xb1tzb3+Lj4+Hj5+Lk3+Pl4t7i6OX////z9/X78PHu5u/l6eXp8ent7erq6+zr7+3l5uLi
6OHe3+Lg4eHe4OTg3tnX3OHf09/f4eHg4Nzi49vh4+Tq5ODb29nItIIeFx8PJR00LS4zLCgi
Hx8bHA0bHx0KCQQlGxEBFyIvDgoPHCAXEBEWGgwMFBITEA0FAwkWFQkSEwwUAAACERYAAAIN
EwQGDBYLAwMbERYXHQ0PCAYAAgYNDxMaHCIqUYKWna6ppKCfo5udmKOinpudn6OoqamwtK6z
q5yNfWdGIxgKCxkJCAYISnSUnqanrq60tri1vsPGwMPEw8/KyMzBxsbGxcnH08vLxsTFvb61
r8CvtK+zt664uLW4sra3tr+9wMG3xMXX2tba1N/Y1NfS3M/Rz8vTysnPztzQz9LX3tPT0czS
w87M0tHQ09PT19fU1dfWz8rV1NXQ0srR0tTS0dPW1dLRz9HW09LO0NzZ09bM2dzS19Pa2tba
0+Hc2trY4OLj5uDi4+Xg5uTn5+jb3uP////7/fT4+fXz6+/r6ern7e3w8Onr6/Dv7+zr7u3l
4+Tj4eDi6+jf4ODl5ODg3+Pe1d/g3uXg4t3j4+To5u7m4+LY19HMuZU3Lh0TICEiPDs2Mzo8
LRsYFyceDwcfBSkGBQ8cCgoKHA8PEA8MCgcGABAIEQMEBggDBAIEAQwFDAYDAgYBAQcDAwMA
AQIDAwwEDBMXHiouJCMNAAMGAAkbFyMtMS0nQWd6kKOsq66opaOkpZGnn56pq7K2v8LAvsW6
vLOljndhNDMZFiYuGxUbUn2Sn6asuLC1vrbJvcPEvb+2xL/BxcXEwsbFwcfCxcS+w7q8vLy5
uLSyr7mur6q2trO4t7a5sLa4vLu/x8vZ3dfX19nY2tvW2tPc1tHQzdLT0trW3tzb2tnd3NTR
z9jT1tPT293Z29nd2NnT09TV29fW2tbd3dbZ1+DY09PS1NLOy83Uz8zPzdXM0dTN3MzZ2dDW
0dXY1trU4N/h5eHj3N/g4eTj4d/d5eH////3+/X6+/z08O/o6+Tr6+nr7+fq5+no7+zb5t/k
397g2uHe3uDg4d3V3dbf19rZzt7P39/X3tXa3NzX1t/W3NjOyszAsXsmMiMWGyYsIyUhKCAW
HyEQExMSCggJCAkCBAcAAAQMChcNCwQGAAAGEAcACAANAAAFAAAIBAwAGAMFAgAGBBkAAA8J
DggBGA8qITBAQkI6PD42KAMULjAoLjVOPTIjFi5ObqCtsKustayto6qhsKuis7nFyMLJy77F
taaTjXFTMyAYEw8WDAkQU3ONm6Wrr6q2sbi0sLm5ury1wb7Cx8PCxMXJwcfKy8fDxMO9wLa7
trW5srW3t7e2tLO7srK5vbm/u7zD0tHY3Nzc2d3a39zY39Da2NDVy9PS09/e297Z39PP0M/W
1M3P09TQ083N1czY0NHQ09fNz9HU3cPTz8jWy9DQy9XM1NHRzs3R087U2NPT09LZ2NjV2tPW
19fV2NPY3d/i4+Xj4eHc4+Li3ePi5eb////49vT68PPt6u/m6uTp6ubs4OXo5u3o6ebe4t7e
3tvb2t/d2t7Z2tva3trb2tnY1dbX2NnY19jY1drU3t3d2tTS1M/Er5FRQi8jKykwLjctJzUr
HRgQHw8YDg0eDxsKCRwIHgwVLBslDhkoFhsOESsiEgURHhQUAA4TFhMMCRQMHwAUBQsTEwwB
DCgsLyssPT06R0FHOTs1KzcxKzc4PD5DOR0iIiQoXaKtt7WztbOzrLKflrauubvAzsjOy7u5
rqOJc10tHRgVEAsJDQsKUG2Pnqiur7Gyub+7wMC+x8jFwsbLycbJxMrLxMTIzM7Cy8HEwbm+
trS5ub6zsqe6tLK1tbe6rbu5vr+8x8jZ1dja0tbU1tvV2s7X3NDUzdDS09nZ2dHX2dLa1NjS
ztLO1dXS2dHT1tXa1dbQ0dXU0tfV19fT1NXW1tLV1tPU0tTS0NHO0tTW2tLV1dLa3dnV1NXY
4eHY29rb3uPq6eXq3uLk5ezp6+zp6uf//v/y9/X39PDu8evr6eLl5+rq4uTh5efi5N/e39ze
2trY19vd2d/d29vZ3d/b2djW2NjZ19jc3NrZ3Nze2+Pa1tXT1MrIsptxQzQVJj0wOTc6Oi4g
HDAqHA0QIiIMCQcbDw4BDxkbCw0cJBUQERQmDAcIFhgLBwALBwwGBAoKBAADBwAHCAMHBAcI
FiMyOj05O0FFSkVMQj46PzY7O0JARTs+LCQnPT9Tjqy2u8DJwbe0t7e3qKi6v8DGzc7Oyrq1
oKF4WC0lMCwTExgcGxUNQHKMoqulrLKzube9tcbCvcPDzcTByMrJycXEuMW+w8TDwcHDvbi0
ury4r7Wrs7OrtKm4tLGzsbO7vL26xMrY2dbZ1tfY29rX2NbX1dTS0szT2NjZ2NXZ1NfX1dXO
y9LT1NXa2tXX19Pe0dja1NrU2dnU2dPb19Tf2N7Z197V2NHX0NTM1tfY1tfY2dfX09bb2s7V
3N3X09na3OLg5ODf29zi5OLg3uLi5+f//v/4+PX39/Xy8e/t7uvs6+nt5Orn7vDk4uPo6OLh
4d7j393d1+HP3NnW3dfd1drcz9jP2NvT29LU1tHa0NnV09TJ1MzDtqKRUTUiKSwyMTgvJy0w
KSEYFg4WDgsHBQQCBgACAQoNDg8OCwcREBkPDAgOEQEKAwAOAgYBAwUACQAAEAAPAQwHAB4c
LTtBRkxUWllZUFVfVE5WTldVUVBMXFtBM0RUc3yWq8C6w8XJyMDBt7a6qKOZu7vBzsPNw7Gp
k2dRQyEiFRskHRQRDQsNJGmJnqmnsaq2tLS4uby/ucG8xsrHy8fFx8bFxsLJzc3Jw8a+vbi4
ure2t7axtbO5tK+zub24tra6wcK8xtDY393b2tzf3N7a4d3b2dPY1tja29ve4tvg4t7m29jP
0NbP0tPP39rY29nc19XS2NTV2tbW187b1NXW1t3W2NbN19TM1M3Yz9XU1NnR2NnN2dHZ2dPc
2Nnc19nS3+Tm6Obl6OTl5ufm5ujo6+n//v/r8/H48O3r6+zo7ufl7eHm4+Hn4OTf5ODZ2tLV
19jY1NjV2NvV1dnZ2NrW09nb1trN2NPT0MzU1NXX19jV1NDT0NHFs6aYd08jMywwLzs2Jigh
GSIMGgkdGRkIBAoUEhAAFyMvCwwgIDEfDiQjLBsTFiUbEwcRERsfEhMhDhEWBgASFBQQHB8z
M0JKTFtdYWRhYFtZUUhLQ0RHR1FIUD86VWlpcY+js8TO19HT0MfFwL6/uKyko8LFxMa8tqON
elU0ERASFhoVEhAJDQUJJVyImaqprbm3tLe3ucLEu73Hy83L1M7LycLIx83J0tHPxMXHu7y8
v723tbOxurG1t6/Ctrazs7y6uMC7yMHW1NfZ0dvc2+HY1dHX1szTz9HWz9re2NrX3tHR2M/Q
0M3O1dHN09DT19DZzNLZ2NPU0djY3NLY0dfX2dnZ2NLR19HY1NHQ0NfZ0tjS3NjU2dXg4NfY
1eHZ29fW3ubq6+bq5ufl4+jo6uzp6+z//v/x9vT49fTv7uzt7fDt7+rq6+bn5ebo5eHe4ubb
3t7b29jY39/c2dzd4N/c1+Dd29nb29zY2dXb3dne2eHZ19TN1tG+uquqlWcsMEVAPz01MTMw
LBwdHiAeGgcaAxQIDQQWAxQPIBIUEQ8PFhYVDwkJCw8cDwcGCwMCAQYHBwIAAQICAAABEh44
QUZPU19iZnBzamZjUFBOTE5SU1NGQjZaeYqeiJm3wM3T2d3c3dbRy8zGwL+7rJ3AzcK2sKSG
YTofIBcyExksIx0SEiAZK1yGlKGuubO0ubm+vsHBv8W9xsbMzM3Jx8PEwcjJzcnKyMLCwr6/
w7uzs7autrC2t6uysrO3sbSxvLy+wcjX3dbY09za29rT2dLX1s/SztbW1NnW3uDb29bb3NTU
0NXR09LV3uDY2dze3Nrc2uHa2Nrc3tnb3trc2t3W2tzX19XU09Lb1NXU293a1tnX39LY2Nbh
1t3W2N7T3ePh6ufr4+Hi5Ojn5Obl4+j////7+PXz+PT17vbv8/Xv9erp5+jm5+bh5+He4t/h
5NzZ2dvZ1trT3NvQ2djc09TZz9rP0tHL18vW2dPc0tvJz9TN0sS+sqaphXUnLCo0ODI0MiIb
HhwXDg0QEQ4GDAABBQAACREVFhQREAYIEhEKDQ8LCAsHBgUCAAMDAQMDAgMAAAAAAAAIDyQ8
RUxRWVhkcXx8bWtrXFxXU0RFTFFILCRcj6OwtKesxczZ3+Xj6drX0NHLwcK9wK6WtLq7r4Fp
QC4VCw4SJxcPEhMQCwoUIlqBlqatsqy3sba8tsDHvMW/ycjKzsPHw8jHxszKzc7JycPDxre7
vLi4ubaytLa1tLW2tra2uba7vL6+xcfQ19jZ19ze2uHY2NPa1dLY0Nnd1ODd3uHd3djU2NPV
z9TP09TQz8zZ3dff1N/a3N7X0tfV3dbg2dfb19PY193Q1M7Z2M/Q0NPX2NfR3NjS2tHX3dTa
1NvS3N3b2+Le5ePr4+fn4+Hm7Ovo6+r////08u/38/Hx7fLt8O/u6+jt5OLj5efl5Obd4dna
29XZ1dXY2N3U2dfW3dXV2NXV1NTV1dTU0dLR1tXU2NfU0s/OzMi+tq2olnweGSo1PTM8MjUj
GxsWEwwKDRgJAAYPAAUACA8ZLB8eDCUiGBoPFBkOIBkUJBkUAAwOFB0MHRcfEwARFR0UGi1B
UVpdWmdpeod5eW1ual5jW1dVVlVDOhovfqa3sryhjb/H19zg4Nfd0c3Qvsi4u7ankZemlnFT
IwoJDA0VHBkTDBAICQsOGFl+l6Oyr7mztbu6vbzAysnIx8XMycjKyNHR0MzQ1tHJzMbEwrrA
v728u7uvtrG4uLi3urq+tra5v765wsXW1NbW1ufk1tnV29LW18/R1tna19zY293X29Hc2tXT
z9jTz9PL2NfX3NPb1d3Z19jV193Z2dXd4drc19Pb3NvW2NnY19PU1Njd29rd2tbc3dfY2Nfg
4eDd4+Td2+Hp7uft6ujo5+vn6ezn8Or//v/08vP08/Dv8Ovs7vDs7Ojp6efj6OPj6eTf4dve
19TU1dbX1NjV1dTW19rT2NLX1tTX1dTT1NbQ19jb29vV2NPS1MnFvLSwnoAoLictNTk2Qik2
Ly0sJhwlHy4aExEaJyAPHys4HhogMyQSDCIxFRQUHBgTGwoVHBQKBwcGDw0MDwwPAw8GAho7
TVtSWl9bZW5oaWZkX2FbWVxXYWJLNhckZp20uca6kYO0ytni4eXb3dzTzszBxL+1o4+JimU6
FhkkCwYbIycKDxIdGREXHleHnKyur7O6tra4vMPAvsbEycbCw8jNzMzKytTRzsvHycTDv7i9
uL+3s7CtubKyuba6tLi6ubezs7y7xsXMz87Y093b2dzW2NHY19jZ29Xa0tbc39/d2drX29rW
1NfS1dDU1dHa39jZ197d1tbV293X3NPh3OHd2d3h2NvM1tvc2dnQ29je2tbW3NnV19LV3dTa
1NrV2NvW4N7b6OPx5uPm4+fk5unp7u7//v/4+Pf39fHy8/Ly7/H19O/u7unr5Ozk4+Pi5Nzd
3djb1tna2+Db2tja2tXY1dXb0NbW29zQ0tLX1tPb1NrRy9HDzcK+vKurkoAgGSUjIDUqKC0m
IyEaHBsYFA4KDgkKCQ4LDRUZGh0lGxYVEBQSExcSFxEJDggPAQULCQ4GBwYHFQgXBAgCACEv
TVZYYWJicG9oZ2l8bV9bXltmXWdnVEQ7XZCwusvJtIeFwNbc4uPr49rUy9K5wLquro9RUE4u
FxANIg4bDRMpHBQNExIUEkd1k6Ost662tbW7uL2/v8S/yMbDycfIysnKzc3Oy8vGxsXEvr+6
tru8uruztLi2uLa5t8DBuba7vMK9w8PS2dvf4Obm4ODa3NjY2Njf3eDe3N7e5N7g29vj2N7Y
2drVy9LN29fV19Tc09jT2dvX3drS4dbj4NTc19vS2NjT2NLS1M7Yz9XV1tvR2tfV3tHW2dnb
2dnd2t7Z2t3e5ezq7OPn5ubp5uvv7+/////t7e738u/v7fDt7Ovu8+no6Ofs5OPe4ubb29fc
3dbW0drVz9bV0tnO0s7V0dPW0tfN1tXO1svW2NHc1tzU0M7Kx8jBu7Wrl3klFhMiJjMsJy8j
JSQRHw4VEw0HCwQKBxIGHB8kGh4nLiYdDzAfJhwWHSMrEhYhHCEODSMjHAgeDQARDhQZGRUl
SldVWWJmXWNhYGZcWE9OPEVOaI2AcFlbZXanr8TKya56ksXS397h4d3ezcy/wr2onXUyLjEU
ExEGDQsQEBAQFA8NCAAEFTd0lKSusrW0tLW4vcbLwMPIysrIy8jRz83K0NjU0M7S0M7EvcLC
u767vb63uri2tbG/vLy6u8G2wMC/xMHK0tze3eLh3+bZ2dPb3NPV3NnZ1t7c2d3Y39PY1Nrf
1NXL0tLP0dLM2drb2tfY19vW1tba3N3b29jX1tXX0tPS19TX09bW1tfU1dbV1tfX19vV1dPf
29fb3d3d3N7j6u3v7Ofm6Ojr6ejt7e/////z9PLy8/Dx6vDt7fHu8e/t6ujq6OXk4+Pj39/a
29jS1dbX19XV1tzT1NXS09vW2dTY2djZ1NfX3djb29vi1tTU0M7EvrezpII3KygwLjsuOD4z
MR4lHSIiJSAmBSAUDREVIiMhPikiFSQpOiMUGjMsHxYbJSUODQ4iKBsHCRgVCgsaCwwHBhYS
KTpERlRWTk5FRk1NQz01MzxIeY+YinlmaoutucrNycKogZ7K2tvj5uPa2NPIurGwoYNALx4c
JggZLyErEyAtKSgLDxslHTx7n6uuvrS6urbCusDAx9C7xsHKysnGxcPJxtLIysW/xMTKvry+
t7y2tbyvvrK5tq+5uLm9uLe5vr64wcDT2drd1t/f3d/a3tja2tPY1tzc2tzd3+Dc3dzZ2tvc
0tPT0tDT1NfY2tzb3Nvb3t/f4N7h4+Ph4eDe3uHZ3tvY2tbY2tje2t7c2OLa2t3c49Tc297g
39/b3eHY3eDf6eLt5eXk4urm5+no8+7////19/Hy7/Tw7+7t7vHv8Ozw7efq6+3n5+Xp6efh
4N/Y2djV1NrS19fQ0NTW1czZ097T1trN4s7K2dfe2dbX2dTOyMC8xbS0mItPHRsuLz5GLjYr
JSQWGA4QDhMOFAIMAAgGEhkgICYfGBwZGhYOFxQXEhQYDwwQDxAKDQ8LFAQAAggLAAoQByUO
ESoyQT5DPDlWPUgzLzw4LiEhdZGfoZGLjKC5wM/Z1M/GqIy30Nfh4uLl09XGxr2fdV9XLxcZ
ExoUDAkOFxcUGAseCw8TGU18l6SmsLG1sbW8vr++wsW7w8PExcTCwcrN0tDNzsbEw7/Dwbu7
uri4uri6uLq3s7a7vLi6vrW/v8HCxMPU4OTm4ODg3+Tf3dfg2dvZ2d/i2eLb5+He49rb2trd
19vU2NrS1tra39jZ3t/d3N3e29vm5d3n4t3h39zf2t7R2NbX09HY19Pd3dzV29nX1tLY3M3W
1uDb3d/X3d/h5+Lq5ung5efk5enn8u7////w8/H16+zr7vHr7e/s9Ozw5urt6O7o5ure5uHh
39va2dfU1djY19fM19LY19bW1NbT1dXT09TW1NjX2drZ09PPz8rDvLi1q5NlJB8nMjxENTss
JygfKhEXEw4kCx4NAhUFGBktPy4/Iyg2KzMcHi0wLRQbODkZDA0pLzEPGCQaFgQlIiMUCBsd
IRImKzwxNTonMC0qHg4XEBAMQn+Xrp6hqajAwsvT2dnKvI+IwM/d2Nre2tvGwrWMdU1UJRUX
EAkLCQkRGBYVFhELCQgRK1uEm6atsra3trq+wsHCxMLFwsfFyMfJx8/Q0NDMzNHHysnIxsHC
wL/Bvb2/vb2/vLm7u77BvL+8w7y9wcvb49/f4+bi3+HZ5dHa3c3a19ve2t/f4t/b4NXd19na
19vW09fU2tTY3Nbg2d7e2eHa3d/f5N/h4Nzh2t3h2uDX2dnX3NfS2Nne39zc2dvd3tna29nd
3drY3+Le3N/h6urs7O7l5evp8fLu8u3////u9ev29Ozq6ejs7uvs8+3x7O/w7e7r5efi5eDk
4tvT3NnV1NfT2NXV1tPQ29TY19bW19LY19fV19jc3trY19bV0cvJybW8q6F5OBsxSUNWQjpE
PzUYIBYeKiUSFA0jIA0gKy0yITIoOywuKx8qKhkWGSwVKRYfEhogGBAWAwkEBgcCBAwMCgIG
AAQGAxAXGRkeHRQMDQcGCRAMHmuRo7O2usbI0NLX2trTzbl9m8TQ2dXW2dvHvqichWFANh0S
FQgJCA8SGBcRExsUEw0SSGeSpaq0tbm8t76/xcbGxsTIysfPxs3OytLO0tTRzMvIzcvFwcHD
w8S/wMC6wbi6vLC+uLm3urm9t8O+yM3c293m4ePj2OPb39vW1dLQ1N3e3d7e4Nvg1t/c2Nva
2dPU3NTV2Nbb29vc3OLh4d7f4+Tf5+Hn4ODd2+bk297b4drZ2Njc2dnd3Nzc3dvd29ri4dnd
2eHZ3N3a5eXY4uXz6+jl4+To6Ozo8/L////19/f5+PDz8/Px8Ovw9fDv7vX49PLu7uvn6unq
5t3f3N3a3N/V1dzU29fZ1Nrd1dfS2tvS1NLW2d3c293V1NHL0snAxLO7rqCDOS0kNj88UEA1
LSYnHSAYEBUOEQwJBgUJExwiJC0qLCgrKCIgHx4jHCIaFxQSFRUYFhMRBwMJAwIAAAwFAgUD
CAMHCAILEQYFCA8JBgYEEwEIDU+GobfAxcvR2NXX3Nbd0cKcd6XN0d3Z0da/vbKppHNFQB0t
HBoOGhcbGB4rKCsZFRUnVnmNoamyu7O7t7nDusPEwsu+ysbGycbKzc3X0tHMzMrJzMbIwsTC
vsC7w7+4vby9u7u5uru8vb+/xMPAytXj4uPk5Onl4t/i6OLc2trd3Ofo5urm5uTk4t/d1uDh
2+Db1dfd4Nza293i4eTe4+Te4OHk6dzi3d/e3dvc39/Y3djX1tjh1t7d4N/a2+Ha4tbh3tnf
293c3t/V3eLh5uTr6uzp5Obo7Ozw8/H////x+ev27e7w7O/u6+vp8Ojv6/D28O/s7O7m6ufn
6Nza2t3d1+TU2tfP1dHS1dPZ0tnR2djP1dLZ3Nnh1NzV0NLQz8jAwLq9t6OFVCUrL0lIUUs5
LigfHhsUDhAQEgIFAAoBExsgKCcsJyAqIyMmJCQpHxooIhYrGh0dIBYTFQQQFAAcCwoZEx8E
FRwVHgcVICAfBxAcEx0REQMaIUJrjqrFwsXOy8vOztTQy7esY2qitrjCtrm+w7itoX9UQRUO
EA0AFhUcFRcVHhsPEA0iV4GZpbGutrW+trm/yMjIx8rGxs3IycrL1dHa1dDZ1MjOzcrHxcjJ
v7/DxcPAv72+wb3Du76/vb7AxcXFz9Pg4+Pq5uPj4enl49vd3M3O2dnY3drj6Ofe3dvc2Nze
39jX2dnW2Nbd3Nvd3+Ph3+Hd4+Pk49rg49zY1tfa4eDX2dvb3Njb4+Dh2N7b3+Lf3drj5dzc
2t3d3t3e4uTi4+jw8O7q5+zu7Ony9/X////z8/Pz8/Dw9PPw8vDs8e/v8fT29PTz9PHu7e/r
6ODe39zf3+DY2dfb19fW1N3b2tnf3t7c2drg3OPg3uHe1tTUzMvGysS9taiddDdGPkxkUHFP
REUyPi4uJR4jChQbDxUhKjY0PzRCPjlKRDk5QjdEMCg8OUEjHiQtJBsYGhsIBgcEGAoNABAT
BAYGCAgGCAoIBwkDAAYGBAgJCRtJepWvtbvJxM3NxcLGwLuukktqoLebkMDKyMGyo4tlPBIS
FwgZJRUvGB47GSoTDhtCa4afqq+xubm8wsPLw8fJxszCxsfLzs3N1NPX0NHR08zJzcnNyMbE
wMPCxL6/w7W7vra8tbm9vLrCx8PD1tbh6N/k4+rl4ePY49bW1NLV1drd2+bh5Oni4t7X3Nrf
2tnb2tjb3OHc3tvf3t/j4OLj5+Pl5+Tk5+Xg4uDd5uDf3N7g4d3j2ePj4OHd3+Lg5NTd3+Ll
3ODc3ujf4+Lh6ubv6O/r5ejm6uvp7un////x9ffx7vDx8fTz8fPv8/Dv9/b29/z69/X19vbz
7Orn6OPg5uTe39zZ1dzX1dva1tvT3uHf3tvg49/l2trZ1t3LyMnHzcjEsrenhlE6S2Vzf3Nc
TUMzJCAWHBcaGg0UDxYWHiMsNjk5QC4sLi0sLScmHCchJB8cISQqHyYaIwUDAQsGCAgFBAYB
AAgBBwACBgcRAQQEBBsEAQACFQoxWYujsLS5vMLFu7W6t7CqqGlQjJiSbaW/w7qsoZBrQiMX
GBshFBglOSwbGSAqHh5OeZeepKqwu7G7wr7LwcPHv8e/ycfDxtDL0c7QytTHzMnMzsjIxcLG
vcDFv8K5wb+8wbm+ybq8v73GycjP1t7j5erm6efi5enh4t7d2NHX09rh3ujf7Ojn497i3dzf
1eHf29rc4OHk49zg4OXl4uLm5OTe4+Dn5N/Z39/i2d7g3d/Z3Nnb3Nvd2eLY5eHb3dnf4tPk
2+Ld2uDc3uTb5OLw6u3n5OXm5uvq7Pf////49/X59fTx8ffz8erw+fDv7PX89Pjz+Pjv9fP0
7+rs5unl4+Tk4+De3dra2dvc1tvY3dnP4d3f4uDg29zg2tvR0c3MyMrDubariXJgU1RqeHV5
SDouLiYZHBUbCQwQDRsPGSEpQjZFNjM+Nj8zMiYpMCYzPTsiICQ0NS4YJS8nEAcSIyIHBRMk
IA0AFCImCAYRFw0KCBUbGwYJCxYLTGJ9mpWxp6qnrqusoZ+gn4tRHlGZh3Kgq6Oak31nTyQL
EQ0QEhUUGRwjJR8PEBFYcpikqq60ub3BwMDBw8bGycnFxcvHysvMzNXW1dPR08/Q1snMysbC
wcbKxMfCw8K/vsDExMDAwMjJzNDa293l6enk6fDo5uXe6dnb3cza1dfg2+Xi39/b5NbZ19ne
2NfX1tzT4NzW3NTd2t7g4OTi4uTg5tTf3tvj2uDi4eTc4eHe39vY3tzh4+Hj4uHl4+Xh4uHi
397g5OXe3uDj6Obs6/Pr5+rn6u/t8vT////39/X29/Ty8e/t7e/x8fHy7vD18vL49/jy9/Lz
7uzt7O3s5unk6ePn3uDb3t3d3N3e39vd4OXi4+jg29vg3tjU0NLUz8rLv8K2n4aOh35zdn90
ekk6Sy9FKh0iKyofEBshLi0yM0A7STM/Ozo/Q0A6MkBDQDE0JTAiLDc8Ix0RKhsXCQ0hKSQO
DxMXFgEQBxkDAwQUGiAHDQ4VBgsSDzBVcXR/goKHho+RjYiGfICDXztYfn1oWE9ZY1pKQRoP
Fw4SEBMhJSkuHyYRFhlXhJ6yqrK7vsPCv8XOyMvJ0M7HycrRz87WztDUzNvLzcjH2sfHzsjN
v7++xcm+wLvBwrbBt7q8uM7Cw8rS5NXm5uDt5evp4uHa497e2dTS2t7f4+Pg3d7i293W1dnV
19rU2dTX3dvd3NjY1t3g4d/i5ePi5eHq6+jj4+bo4eTf49/i4d/d4uPh5eXl6eTi5eTn5eDk
3+Lc4N/d4uPb3ebx7e3l5+rr6Ozs7/D////29/j5+vH29fX09fL39vf19v/9+fb5/vr5+fX7
8e7v7fLz7+/u8PDr7Ofr6OLk4ePg5efm4+rq7+jn5ufj4eDX2dTR1dPTzMC9pbWvrJqMlJ+S
emxSRDItLjUeEBEZHRkQKywwMjAvNjY3NzY9Mi0vMiwsLi4uLCssKCcjJiAcFgULCwgIDgQJ
CwYJCggHBQcHBwMCAAcCGQoPFAkfDwspQlRcanB4hXuIf4SAfXdncnh4hYJyeGhYLSMkHSAc
HikeGx81RjE2KiUlJCZheqCqtbiytrW/wMDGx8nGwsu7y8nGz8nSz9LX0NTNzsnN0MjGwcbG
wsTDx8fGw8DCwL3AuLu+vsTHyMza3uLn5err6efp6unu6OPd1dLJzdnl6OPp6+fs5eHg3eHg
3uHg397f6ePk5d3k2+Dg5uzk5eXi7dzl4+Xl4eTj5Obf4uDd3Nfj3uLg5eTk4ePm5d/h5uHo
3dzY2OPX4N/h5OLn6PDu5ufm7u7v8e///v/5/Pj38fX28/X39/b49O/3+Pb49//48Pnz/vLy
8PDv6+zv7vro7O7m7OTp5t/l3ejh4+nj4N3n8+Pq3+nm3d/U09TX2MvSzsjDssXTzMnBq5iS
h2xOQDwzKyohHRoSEQwVNDArMC04MjEwOEQ1MzEtOy8qLi1LLjcxKjMlNiMbMRIfBREiGB8J
FCESFgASHBsNAgQYGhEFFAwdHRQQNxUNFzxGUUpPT2FaZ2lmZlxSQUBWSU0wJR0fHQQDCxAL
DBATFjElJSIlHgoTDxhbf56ur7K5v7bBvcTEzMnJyMzFyMnS1NfR0NHR087P0s3Qy8/GwsvG
xsTGzsfFwcHAwb/CusHCwsnI0NjY4OHo6uvx6Ors5vDo5+Th4Njd3+Hp5ubr7e7l6uLj4d/Z
3OTV3OLU19bU2tvW297m5enl5eXh5dzj3+He4N/f4Obb59/f39zc3+Lk3uLf5Obl5ebm5uPk
4ePj4uLl4+Pi5OTp8PPp7Ort6+7x7/T//v/09fT28fP17vXw8fDy8/Dz+/n79vj3+ff2+Pjz
9O7x8PDy7/Ht7/Hv6ern4+fj4+bl7Ofo6ezx7fHu7u/q5+Pj2drZ2dvd29PLy+Lg2cXHv7ig
jIx3Z0RHUk07JCY2KScROEVFPi04Q0k8NkdHQD05NzVBRkIpKidIRSwmMDM7HBQSKR4WCRUg
EAQEBAoGBQ0PBgcDAQMPBQoJAwgADQwEBgcYHCksMjlDSU5LTUMeERkfJyoqKBcREQkMDg4R
ExcWHCErOjIlFRwOJBlkh6GvtLu7wsTJysXPzM7Mzc/Qz9HQ0tbV0tTW0dHW2dTV1M3JxcDH
wcnDxsrEzcDAxLzFwcDBwMfE1N3b49/o6ujr5fDq4uXf597d2tLa1eHk4ezn6unm6N3f5d3h
3uLe3N3Z297d3dzc3Nrm6+rr4uPk6ebm6erp5uTi6+ni4OTl5eHk3+nr4unj6Ojj6ePn5+fs
4OTj5uvg4uLh5+Lm6/Hw7Ojq8fPr8u7//v/2+ff28/ju8/Lz9PTy8/X6/vr/+v/99/f8//r0
8fjz+fDw9vjv8PLw9O7l6Ozu6unk6ebn7e3y9/P37fHt5u7f3uTg5tvZ1t3W1uXf2MGxvKmi
lYuGdWJbPkE7LzIdHygnKzA2LTIqNjY3KTAoKzAzMSgtJSorIi0vNCQkLCUhIhQMDwsPDRII
AQIBAwUFAAUDAAQMBQYCAQQEBgAEDg0DABYPEQADBQ4XIy83GxESFRQdHykwIxMmFh4OCyUZ
JyouOig+QTcpJh4sFS1wjK6ttL65w8HHxsjRyMzLwMvBzcjIztPX0NHSytfMzMrH0sfExcXI
w8TEwczIxMDEwbzGvb/BvsbL0d7b4N/q7Ojn4+Xj5eTa4djh3Nbc3ufm5ujr8uvm6uHh4N/h
3Obc3Nnb3uHh3Nrb3N3h6evn5+Xk5ebt6eTh5ejn4OXi5+Le3d/m5uTj5eno5unk3+Lo6+Hk
4+fj4t3b2+Da39zj4e3s6Ofp7PHr8u7//v/5+/b+8/T18/nz9vfz+PD2+Pj/9vXz+/z09/Py
8u708PX28Pbv8ezj7uPt5uLo2uXl6unh7enu7/Dx7e7q5+be3Nze39zd2trY5ObP1MvLzLKc
lpmmkn5QQkI6NykkIyMcGS4mMSgvKCsvLDAkJzkoKyI0ODIpJCk3LC4kLDkuIBwbKyMSCiId
GwoCGyAgDhUsGxsMHCgmJQsHJx8WHBgVCh4nFSEgGxIVGSIYIx8cJiw4LC8uOyojGB0lIBMQ
FxkkMCYlNiwlGhcREDl5k6quuLq+wMLFxsbKy8zLx8bFydLR0c3W0dTR0NTR0dPRzsnJysfF
xsvLy8/Oy8jIxsfMyMTIyMzU2+Di5OLm5+vs6fHq5ejl6OPd3dbi4OXq6fLv5ebo5t/a3uPo
4Nnf3ODU3tzf4dbi2ODd4+fn5OTj6t7m5OXq5ebm4+re4+Pf5Nvl4+Tj5uPo5+np5uTo6ujo
5ebi6Obl4eXo5ufn6vXz6+zm8/X1+O///v/7//n9+PL28fT29vby+fL2+Pf4+Pn69/r09fDx
7vL08PP29fbp7O3q5ujo4+nx7erp6Ofo6Ovx8PLv7u7s7Obg2t7i39/f297U59rj5enl4+Hd
2tTPv7eTUENUPjo1KzMlMCEsRzlANUBFP0sxOzEzISoqIigoKjczLDE4MygdNig3GxMeICIK
Cx4XDAoOGQwABQYUCBYPHCgdEgUOBAAAAQAAAQIFAAQKBwYIEQ4RGRogJSQkIxkVCBkLChUZ
KRopLzc3KiwXGR8TGl98nLO6urzBxMnIycrM0c3OydPOzM/R1NbZ09HUzdzR1NDVz8XFxsTP
xsXEzdjHwsHExbvAx8nKy8nR19fa4N7u6Oft5Ono4+ng4dbj3dbY3d3g4ufd5OPf5+De1tzd
0+Tg3tzW3OHj4N3e3ufj5OPp5ufo7ebq6OXp5unr7Ofp6efl4+fl5ePp5+3r6+3r7uzo6+np
7O3l6erl5+vk5+Ty7PHx7/Xr7vLv9O///v/4+/33+vj5+PX3+vb69/n7+v74+Pj7//n///r3
9/f39Pf49ff29PTw8O7s7urs7u/y7+vs8vX09/nz9PLy8evi6uXm4+Pp4d3f2/Dv9vPu8+Xo
493i1s20b2VPRzQuLzYdJB0dKCkoMycsJykvJyAgKyUjIyAkHCMjHyYkJSMhHCgbGRgVEQkJ
CgcLDAYKAgIFCgoKCxYPHRIMFQ0ZAQsCAAkADQgLIAUcCQkbFx8UGikrLycuLigiBxInIyYb
IjFEOCkqLzUqGRwSPXOco7Syur3Dx8fKxcTJx8zIxMjG0svI09DT0c7Vy8zR0dLMzMXLyMfH
wcbHycvGy8fHxL7GwsfGw87X3+Hh4uLn6+nr5uPm5eXn3uHd3N3e4eXp6O3u7ezt6OLk4OXk
4+Pj4+Db4+Hg4Nrl4efn6Onn6Onl797p5Obu5+Xm5u3h5OLk597m4+Hj5erh5ujm7+Pq6ePu
5Obk4uje5uTj5+Tp6enw6/Dq6u3x7/D//v/4//n7//z2/Pf9/P319vb9///6/f37+P35//r3
+fn9+PX79/3u8vHr7Ovt6+3r5uzp7ezl8vDy8+337fHz6urc4uXi49zh3OHe4Oru8vr07/Px
6Ong4NvLq2hGRTQtHyMgIhsZHSQjJSUpIzMkICAiKR0dJSMrHCkkHCAWJxwcNh8vFRgjIh8H
BhwXGQQLJxkaDhUkKBsRHCEmKSISJyINCRsZGxwbCA4NIBkWFhkpIikoLUIkOA8eKRgLEhYr
NDA5OTcvKzk2Mh4mTYObpbK1vsK7yL/IxsTLycvLzNDKxcvQ0dDIz8jSzMjUztPRysrJyc7J
zMjL0szPyc3RzcfGxc7Ly9Xd6erl5+Ls6+Tp5enr5Ojf5uXk293l6Orp5eXs7unq4d7j3tzf
2uPZ2trN39nf4dfg2+Lj4ufm6eXi6ODk6+bm4+rk6ezm6eLk5OPg4OPi5ujm6urn6uvm5+fp
6+jh5uTn5Obh4+Tj5ezy7+/s5+/t8fL//v/4+/L7+Pj39Pf0+fbz+Pj///389/j5+Pn0+vn0
+PX29/P28/fx8/Tu7uzt7fDt7O3x8uzx7fH09vb19vL07+nk5Ofi4uPk5eLf5fLz8vf////8
+fbw7uLZzb5rR0dWSjgmJyo1IhkjPTksHC5AOzEuKDMtOD40HiM5LycwJjgzHCMkNyoiGign
IRcTISAdEhAkJBcNEh4WGxkaFh0lFBgWEwoOEQINCgkKBwoMExkdHSYmIysjIBUPCgoOFhUZ
LjY5Niw4PkQzKUNMfpmkqK21w8O9xMTLzMfN0NTSz9PQzdDR1NLS09HYz9HU1dLQzMnWy8rK
ydPJys3J1MLFxbzKwsfKxNbZ4OHf49/o6uHo4uri4OTb4dHX3dvj3+fp5ezq7+3n4+Hg4uLi
4+Ph4d3c297b2uLh5Obn6enp5+zt6err7O3s7u3r6+vr5ubr6efr4uvs5u3o7ezo8ejt7vDy
6u3s6Ozi5+fm6ePm6Ozu7/Lu7/Lr7u///v/5/Pn8+fny9Pf3+Pr19Pj9/v/6+v7+/Pn8/vv4
9vz6+vT1+/739/b28/Lv7PD07+7x8vDy7vL3+vb29vz27Ozk5+bj5eTn4evh5e/v8vn6/Pf/
+fT38+3p0Myqc1dJPDpNNSEeJiYqIRQkOSYeJB0qIx4aHBgfGiMQDyIuJyIiJiElHyMjISke
HhkbGBERGBYRExUWFxINGBYXFxgmHCEXFRoZLAwHBAoGBwkSFR4oKiAhLzgpHBMgICMTFS9A
PkQ0Qkc1RVBQV1OOlqaytLy/tbu4xcHHx8TLzNPPyNTK0MzK0NHY08vRx9XO0czN0czNzc3N
w8LHxM3Fy87QzMjLy8zO09Pd4OPi3dzh4+jl5uLn4uDi4d/h2uHe4+Tn5Ozq8Ozo4ubm5uTp
5OLh4d7h3d/c4eTo5ufp5ujo7uvq7fDx8O7u8fbs6+nm6+Lq5ebq5uTl5+vq5eXt6OTu7eLn
4+Tg4OXk4+je5ebs4+jr6vTp5uvp8eb//v/+//v//Pr69fz6+Pf2/v/8+fz/9Pz6/f749/j4
+vX29fb7+Pv3+vjw8Ozu8O7x7PDp6ezq8u709+/18fPz5ujk7urn6t/i5uTh6/Lw8/Tx9vL3
9/b79PDo49nBr3JMSDItLCsfJRoYGh8oISEfICAXKSQtMioxHxwuJyodNDQ4JiU0PkgzIDM4
MikhLC8wKycxJzYsKiM5Jh4kNionLiYlHykxJikXKREcGRYeHxsgJDAuOyQrKyMXFRYvLjg2
QTAzQD5RPk9ufIydoKa0t7u2vb7DxsrKyMjJy8zMz8/PzNDPzNPP0dLT09TTz9PQz8vKzM3J
x8rLy9LRz9HKycnI0M7M3d/k5ufq6+ns6fDt6+7m6uvk6t/k5OHo4+fp5+3r7uzu6uHm5ebp
5eTi4uTf397b3drl2+Pn5ubm4+fn8+js6evx6Ovv6PDl7Ojp6Ojm6Ofo5+np6u3o8+zq7enr
5+nn6Orl5ujo6ebt6/H08PPr8fDz9u3//v/9//z5+vr89vf49vzx/vj///z89/799vv6+fj5
8Pjz8/j49/v59/jx7PDx8u/08PDq7Ozu8PX29fXy9fTy8Obq5+fr5+jl5+fj8vf7//339vX/
//v4+/n35d/P0bB5TFRKQkI3Mjs4JR0tNjUnKzo/Jys4MjA0IzAlKzQ7MyosRCEzIDIzKScs
LzMxJyElKB8OFR4jGR4fGx8WFhwzIhojHRwVGR0cGRMDDw0PFRwbIiciKyUfGxodHCceKzY2
PD5IR0RUcYqVoqWrsbi6vL2+vLzAwMXLxcrL0tDO0tXT0dTU0tHZ0dLU0djR1tPQ1cnO0M7V
yMvK0NXSzc3VzsrIyc3Q1OLh5end5dvl5eXs5+Dk3OTi49vj4d7h5Ojp6uvn6ufg3uDm5Onl
4OPl3d7Y4dzd4Nzg3eLp5uTo7ejp7Oby8ezs7O/t7u7r6+vq6+zv7Onp5uzq6+vo6ePs7ujv
8PDp6eXn6evm6OXx6+zs7fbz6+/u+u3//v/7+Pj7//z8+vn5+/z5/v/////9+vf+//z8+fz8
+/f6+//++/n5+/r29PP3/PL08vT59fP2+/35+/f6/Pf68vbu8Ork8OPs6eTq7v/39/r0/PD0
9/n58Pbx4urT0L2jcktCQDI2Li8dHiAXHBceGxskIyEjHyMlICIkKRwfICUkIigmKCs2Ligu
JyswIR8cIBkbIx8ZHioeLSgfKSAxJycgHigeJyMcKB4pEhYjHSgeKDQtMxooLywnICtCRktR
UmtveYKMk6W2tri+wL/Ct7y7wbzExMPNzMjT0M3LyNPP0s3L09XX19bX0M7Q0dDMzMrOysvL
ytHLztDK0svNzMDPyMvV2eHc5Obi5eDr7Ovu6Ofo5+bf5uXj4Nzj6efp6O7s6u3w7ero6urp
4uPk5eLg4t/i4+Pn4uvr6uzr7Ojo8+ry7fH58+3u8vPm6env7Onr6evr7O3o6uvo7Obu7Ovu
5efl6erj6+jp7ebp6+7u6uvo7O3v6+3///////r+/f//+//++v/x+/r//vr29//79Pz4+vX2
9PH39vj48//1/Pnx9O/08uz26O/m6O7q9/H29vb78vfu7vftlNvm/Ozn5+Tn9v379fn39fj0
9fny8vXt6+ne1ca/rHRJSDg3OCwrJR8bFxsYFhUUGRcbIyA3IB4eIS0mIiAlLyQxKiw4KDgm
MS0nMiIqKC0tICQ8ODYsKiMiMykuNDIiHyEuJC0xJBsgLSImFSc4NComNDclGx80SUNARlli
d3uFkJycqrS5wMHKw7+3ury7vsC7xMDJysbQydDPxtLL0dPP09PV2dfZzdPX1dHRzdfOy87P
zdLN1s3NztLS0MrOydHa2ODc5ufm6eLn7erq6e7q5Ork5ODl5+Dj6+jp5u3q7u/i5Obm6Ojm
5ufj4eLe39zd49/k5OTp5+Tr6+3r6+nx8O/t6u/s6fDo7uzq7Orp5ufq4uvj6+zj7ebv8Orr
3+fs7uji5u3q6uvx8u/y6+zt6ezt9+3////49/r//P///f77+vz5//7///37+P/6+/z7+vv4
+fj5+Pb5+/f5+vv49vn29Pb18PLw8PD19Pn49/n6+fjx8/Xx8PDs6ubm4ebn+P//+/z7+/7+
//76+/r2+PHo29nSwrd/YFpKQDI7NC81JTIpLi0pKyk5OTwwIyo4PT82PkM6LCYtQjIzMjFH
NjQqKUs/KyQyMDotJygvIhwfFxckIh0fHx4XIBYVGBYbFhoaGSAdJygpKCspO0pWVV5odnuH
maKorq+yubzEyMXIycrDwMG/xcjExcfO0cjMzdTT0NjV29bU09TX2dja1NLW1NXRzdHQ0cvL
yNbV0dHO29HNz8rWz9DY2t/c4Obl6t7n5+Tm5ufk3uLe49/f4dbk5Ofp5/Hq7Orn5ePo6ebo
5+bi4+Le4N/e4eLl5+bo5Ofq8+3w8+7w9fPy8fLz9fLw7vP09u3s6PLv6evs8e7r8Ojr7/Lx
6+zt7vXi7+np8Ors7fLx7Oru7vHu8ur//v/19/7////++/r9+vj1//v//v35+vv7+vv3+fz7
+vv3/Pv7+/38/P/7/Pz5+v779/by+fj6+/n8/P79//70+fb09/Xz9+np6e3u/fz//P72+fb8
+/n9+fv88fjp6d3T0cmzjmRaWUk+PjcxMSwpJyEcGVgcIhgmHiMXGhYbHBgdIx4lLis0JCsq
ICksLCUcKiweHycpJCYXFxwcIhsnHhwbFScRGw4TFBQUFRsbFSMcKCAlPkNiam1+kI6WmKGr
sbe6uby+xcfDy8fSycjDwsTAwcLNzMjMyMzQycrLyNPL0srW0dXR2tPX0dXNysvN0NDNxc3N
zs3My9fMz8/RzNHOy9LY193d5Ovn4+Tk5unm5ebl5+Tj493g3uHl5ezt7+3l8uvq5+Tp7OTo
4uvm4+Hj5OXf4+Lo5uju6ezv8PPq9/H1+vPv8vr17/Lu8vTq6PDx7ebr7PHu6e/t7uzx9ePu
6urp6Ozo8PHh6t7z7e7u6e7m7ezn9Or//v/9///////////8/f39//3+//7//fr8///+/v/+
+vn9/fz/+f/1//34//n59Pn48/bx9fr6//r8//b89/b39PXz8/Tt8ezq7Ovz9vz29/b0+fn8
/vn69/r48vbt7OXj2tfLwKuAX0RCPDE7LiwwJSUaGhsZJCMkGBgkIC0YIiQgIx8iNjQoKkI0
LjEvK0RFKS5MSUIoLDY1LhgjRUQwKi8rIyckIycnJRUlISAlKiQbJjRAXH+Il56bpqKxtKi2
uMC4vL+/v77JyMPHyMfIw8LBxsTGxMXLxsjLzNHOzdDO09TS0M/U1NjY0tLN0M/OzcvQz9DM
zdXY0tXV2tXQzszV19re4uPl4+To6OTh6unr6+3p5Obi6OHd3t/l4+fp7PTy8Ors7eTn6Onq
6eLj5eXi5OPi4tvl5ubl5evr5+jr9+vy8O3y7/Py7fXp7+7r8Ovt6+7t6ers7PLq7ejy8Ozy
6+/q7+/s6+/t7ezw8ffz7Ozp8vLs+uz////8/vj+/P//+Pz79fr0//3///r5/f//8vz6/v77
+fv6+f39/v/0/v32+vn/+vP89fz59/n9//////z9+fL5/fv39vH18uvn6evz/vP3+/n9+vv8
//34/P//+vj29PHm5ODf18zBppZ1TkRVUkQzLjU1NywpLi80HCUvNCwuMSEgNCM7JiYxMDMm
KjY5KyUlLzUpNjI2JCobIyMcFhUbICEbHyIUGhIUHB0gFxceJSYjMFJ3hqGfpaqoqq+5ubS6
v8bCxb/DycjGx8bM0MzIxsXKxcTJx87MydDOzs3N1NXR0dHS1NbZ0dXX0NPK0tTP08rO0tXP
08zL09fTy8zT0dLO1tvi2eDg4OPh5Nzm4+Lj5Ofr4Obg5N3o49vg4ujv6fHu9Ozm6eTr6eXq
4eni4eLd4ubp5eHh3uXl5+fs7fDy9Ob07u/w8PT27/fw9/bx9vDw9fTy7O3v8fP18vX08O/1
9vPv8vbv6/Ts7+767e/t7vLw7u3p/uj////6/Pv///////78+/v9//////v8/f///v37+/r9
/vv6/f///fr4///9+/n///r6/P/++vr///////7///r8+f76+fnv9urw8unz8Pj27fPx///4
/fv//vv9///t6efp6unl4dTRw7+2o4ZoV09SRjkrMDcvNSoqMSclJCkeHyckKiAnLSswJSIc
ISMgLhghJi8dICUeIRsYIR4aJRsiGBUaIS0cHhoZIhsgIBwmIzBBbIuWoqiqt7i6urzCw8nH
ysrOzcXKyMjMzsfLzdLIwsPDy8zKxsbP0MzNz9jPzdDQ2NLL1NXQ1tbV09HQ09DP09DW09DR
0dXVzdTO1dHL0crV1t7h2t7f4eLi5trk5OPk5Ojo4+bk4+Hg4N7e5Ojw8PHz8O/v6+/s6+/v
6+ro6+nm5OXs6eXp7Ofs6+nv8/L0+evt9Pn39vP08/jq8uzv8+7t7e7t7+3s6uzu8eX18eny
6fDv6vPm8Ozp9Oz17e/w7fDu7PDy8uv//v/9//v//////P///v/7//////v5////+vz8//z+
+/v//vr5+v/5/Pz4//P6/fn9+/n0+//9/vz///v/9ff+9v35+/fw8+jl6erw9PDt6vHu9/r6
/fn4+/n99PDu8u/p6+3m4eXh1dHMyLOqnIxtWk1ORDQyMCk6JCoqKTMpIyMnPyg7Hyg8JjMn
JDAnJRkbMDgmJyI7LScjKSwuJxwiLTUVDCUwMx4nKSg1OzNDS2KDnaGpqLu0s7i9vMK+x8LQ
x8zKzM3Fy8zJzc3RzsjDvsnAwcTBz8HNzsfRy9DTzNPI2NLS1dnT1tLZ1dPT0tTT0tPQ1NbT
0tTT19HW1tPZ09PY2uLg3dzh4+Tn5+fo4Obi5+7q5eff7OHi4+Do6/P07vXy8fDo5ezw8Ozp
7/Pq4uHg5+Pk5+Pt6Ojr5e3n7PTt9ub08+317vrw8vLq9fD28vPz7vHw6e/p8vLy9PLw8u/0
8vPw7+7w6+rw8e/x8/Ht8+7w7e7x8uv//v/7//7///7//P///f77///5/fn+/P/9/P7++vr6
//j9/f39+/z8/v/9+vn6+//9+Pn5+Pz//////v7/9vz+9/r8+fTz8u/t6unx9Pb07+vy+P72
+v3////8/fv18O708PXu7vPs5N3Y3dnGwLCyq5CFfX57cXBYX2RoYFdZWEtCKzM5SUFCLjUv
NS0nNTYvJRw1NDAhGiYwGxwUIikmFhomJCMeIyMkJCYqKENYf4qcqa2zsr2+wby7wb/Bw8PL
0M/O0snKysvQyc/OytHGyMXDxsbFxcfU1c3P1Nnc2tbT3NnW29be3dvb19vZ2NXY2dTX0tTU
1NnX1NzW3NnP1dPk4tzj4ejg3OPj7Nzg4t/q5ujq4ujk5t/k4dfk3uft6fPq7+vr8eXv8ezx
6O3n6evo6+nk6efq6Ofp6Ort7/Lz7/Ty8PL09vf18/X09fX18/f49vPx8fPx9PX1+/n09/X3
9fj58vTw9O/y+vX49fX4+Pf29fXv8uv//v/6/v7//P////7//vz7/f3////9///+/P38/vn+
/v/+//r//v///Pj//vr3/f3//vz6//3//fz//v/9/P//+/X//v369+7x8u/3+fLz8fbu8O73
+u3y8v//7vPr+PTn8er17+vr6ujg3tbX2c3Mxbm3pJ6MhpOTk5SVoZ2WlI97cVpPQUlGLC8x
ODYwNSMiJy0qJSYZJCkaHiAeFyEeHSEeJSgaKSUpJixIboCQmaivure7vcfHwbvGzcrExMzX
1djYzNbR0szPz87VzdDTxcrFzM3L1MXPzsnXzNTVzdrR0NjV2tve3dbe2NXP19LT18/PzNLX
x9HPztvR1szX1NLc2+Pf4ePe5efj5t7k39/k4uHk5OTi6+Ll4eHg4uXr6u7x7/Pv7+nu8PXv
6ufm6Ovu7uzr6ePs7PDo8e3y9vT3/Pb19Pf5+Pz59vby9vX39vj6/Pr48fbu9fP29O749u32
8fXv8PLt8vTq8+z27vHv8PLq6/Dt9+v//v/9/v///////////////v////////39//v+/fv/
//n6/////vv1///4/vj///n////9/P/+/f/+//3++f3++v//+ffz9+vu8e79+fz18vDt8vbv
9PD08/H17vHs7evq7+708+/z5+3o5efc2tnX1tHCwby8u7e5vb+8vLaxtaqtop6blINvYmRb
VVJMTkNHQDZCR0MmJjswNhkhPUUrIC81OjUrNUFNZHqQnaqptrC4u7rDvMTIyci/x8PKysfV
0dLNzszI0czQ0snU0MzKxszIyM3Ny8vLytHY0tPS1tTV1dTV2dje2Nra2dnW1tbV0s/T09XV
09fV2N7W09XV2N3j5ePk5eTk5+rq6+Pk5+rv6+/t8fHr7+nl5OLt5/Hz8vnw9PL08+/x8vb5
7urs8fPq7eXo6+ju6PDu6fHu8PTw+vH49e/7+PX38/nt9fT19fL39/f09fPx9Pf08/H4+fT4
9vj08/bv9PTv9PD49/f59Pj29PXq++r////7//v//f3//fn6+f/4/////f3+////+f76/fz4
+vf///3/9v/6+f73/Pz+//r//f37/v7//v/+//78///+/Pf/+vPz8O/u9PT9//j6+fP09vb8
9PLu9Pn47uzt9O/u7/L9+fPx+PH57ezq5+/h3d7d2tLU1dDX1Nrd3djOw8fAwrO3sbOjqZiY
mZmej3hnVEc0LSwuLDcjLSwtJSwpLykjMC1DYX2Pl6qmrquytb29wMPJydC/ycrFx8TFycnT
1dTKzsjMzc7MzcvRz9HJysXGys7O0MnNztLV1dXU09fU1dbZ2d3f2N7e1tzV2NjW2s/W3NjY
1tne2d3b1dbX29/n4+jm4+Hk6e3l5eTq6uns6/fy6u/r7d/o4+Pg6O70+fTw8vLw8evx7vLw
6/To7/Hq7uXu7uLr6fPs6O309Pfy9/H6+fT49Pf89fn2+f34+Pr3+vT39PT39vX19vX49/X/
/f35///18vb0+ff6+vz6/P718vPu/e////////7///3///z////8/v/////8//////z//fv/
/v3////9/fz////9+v7//vz8//////7////////+////+/3////+/vXz+Pb+/f/8/Pv2/v71
+/n3+PHy6vbg6uno8+/y8fH56PHv5erk7t/m3tne1djV1drP4N7Y49rTy8nLwcbAu7q7t7Gx
sq6uqaCblIdjPyktLy42KiwvMCwuKyc/YXuMl6KorrK8wsTEv8HJysrKycjLy87T0M/Q0NLX
1tjX0tDS19PT0tnY2tfS1M7N0c3N0dHRztTV19XS1tPS3NbX2N3d3Nrd2tvY2tbZ2NLY1NbY
1tvU19jR19je4eTo5N7j3OLi5Ofl6uLm5uTq5+3v7PHo6ebn4+Pn6O709/n38/f19PHz8/Xz
8fH09vbv8Ov07+nu7Pf48/T2+fn1+/n7/Pz8+/z9+v/5+/38//r+/v///Pj8+vj0+fL9/Pb8
+Pj29vrs+fTy+Pj9+fr6+Pj39/bz9PH//v/7/Pr//f//////+/36+v/+/f/////69fz+/P77
/fr9/v38/fr9+vj8/vn6/Pn/9fn6//79+P39//z6+///8fz+///y9+7y7/j8+f79+P/1/Pj2
+vP27/Lv6+bj5unp6+/v6u7x8fLy7ufm6Obo5eLg3+DZ3N3b4ODh5OHWzs7NzcnLy8vKycTD
wsC6u7S0s6iflolqU1RGUT5BRlh4ho6YnKaytLK+wsbOzsvTzsTHzNrU0NbJztDP1tDR0tXb
zNnS2NjP09PT2NLZ1tXPyNLLw8rJ1NLQ09XZ0tHQz9LS1dLU2Njc2tXc1tvZ2trW0tXX1tbY
1dnV1tTT1dXf5ebq5OTe3t7i7Ovn7OXt7+Lr8O3w7fLn8Orp5Obw7vP3+vz39/b69vb09vb2
9PTw9PXw9Ozq7unx8/by9Pb07/Ty//f8+/j++/z9+Pz1/Pf4+fb8+fT4+fvz+PHt8/L3+/b/
8/v48/bx9Pnz/fz8//38+Pr89vXw8e7//v8=

--PART-BOUNDARY=.19805061827.ZM17851.beijing.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 May  6 20:36:39 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id UAA03769 for info-performer-dist@holodeck.engr.sgi.com; Wed, 6 May 1998 20:24: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 UAA03742 for <info-performer@holodeck.engr.sgi.com>; Wed, 6 May 1998 20:24: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 UAA21382748
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 6 May 1998 20:24:30 -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 UAA08545
	for <info-Performer@sgi.com>; Wed, 6 May 1998 20:24:27 -0700 (PDT)
	mail_from (liuxy@ihpc.nus.edu.sg)
Received: (from smap@localhost)
          by aba.ihpc.nus.edu.sg (8.8.5/8.8.4)
	  id LAA13235; Thu, 7 May 1998 11:23:40 +0800 (SGT)
Received: from liuxy.nsrc.nus.sg(137.132.15.179) by aba.nsrc.nus.sg via smap (V1.3)
	id sma013233; Thu May  7 11:23:35 1998
Message-ID: <35512962.7D47@ihpc.nus.edu.sg>
Date: Thu, 07 May 1998 11:24:18 +0800
From: Liu Xiaoyan <liuxy@ihpc.nus.edu.sg>
Organization: Institute of High Performance Computing
X-Mailer: Mozilla 3.0 (Win95; I)
MIME-Version: 1.0
To: "Gamble, Murray - Kan AV" <gamblem@kan.marconi.ca>
CC: SGI Performer Info <info-Performer@sgi.com>
Subject: Re: Missile Trails
References: <3550835E@avgate.kan.marconi.ca>
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 7bit
Status: O

> Would anyone be kind enough to provide a block of code illustrating how to
> correctly setup pfuSmoke to produce missile trails?  I have been trying on
> and off now for a few weeks and have not had any luck.  After setting the
> basic parameters and starting the smoke, I simply see no visual results.  It
> looks pretty straight forward, but a kick start from knowledgeable minds
> would be most appreciated.

The following code can give you a very simple visual effect. The smoke
structure is attached to a pfGeode and drawn in the DRAW callback. 

But, I don't how to disable or delete fires that should not be drawn
after
time is over. When I have multiple fire sturctures, they are all
displayed
even the time for that one expires. 

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

pfuInitSmokes();  // call before pfConfig

int smoke_draw(pfTraverser *,void *)
{
 pfVec3 eye;
 CAVEGetPosition(CAVEEye,eye.vec);
 pfuDrawSmokes(eye);
 return PFTRAV_CONT;
}
pfDCS * create_scene(pfChannel *chan)
{
 pfScene *scene = new pfScene;
 pfGeoState *gstate = new pfGeoState;
 pfDCS *dcs = new pfDCS;
 gstate->setMode(PFSTATE_ENLIGHTING, PF_ON);
 gstate->setMode(PFSTATE_CULLFACE, PFCF_OFF);
 scene->setGState(gstate);
 scene->addChild(new pfLightSource);
 scene->addChild(dcs);
 chan->setScene(scene);
 create_smoke(dcs);
 return dcs;
}

void create_smoke(pfGroup *parent)
{
 pfuSmoke *smoke;
 pfVec3 origin, dir;
 pfGeode *node;
 pfSphere bsph;
 origin[0] = origin[2] = 0; origin[1] = 5;
 dir[0] = dir[2] = 1; dir[1] = 1;
 smoke = pfuNewSmoke();
 pfuSmokeType(smoke,PFUSMOKE_DUST); //SMOKE);
 pfuSmokeOrigin(smoke,origin,1.0f);
 pfuSmokeVelocity(smoke,3.0f,2.0f);
 pfuSmokeDir(smoke,dir);
 pfuSmokeMode(smoke,PFUSMOKE_START);
 pfuSmokeDuration(smoke,15.0f);
 node = new pfGeode;
 parent->addChild(node);
 bsph.radius = 10.0f;
 bsph.center = origin;
 node->setBound(&bsph,PFBOUND_STATIC);
 node->setTravFuncs(PFTRAV_DRAW,smoke_draw,NULL);
 node->setTravData(PFTRAV_DRAW,smoke);
}


***********************************************************************
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  Thu May  7 01:21:27 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id BAA04238 for info-performer-dist@holodeck.engr.sgi.com; Thu, 7 May 1998 01:02: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 BAA04211 for <info-performer@holodeck.engr.sgi.com>; Thu, 7 May 1998 01:02: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 BAA21674876
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 7 May 1998 01:02:22 -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 BAA07984
	for <info-performer@sgi.com>; Thu, 7 May 1998 01:02:19 -0700 (PDT)
	mail_from (Ruddle@cardiff.ac.uk)
Received: from thor.cf.ac.uk by crane.cf.ac.uk with SMTP-LOC (PP);
          Thu, 7 May 1998 08:58:10 +0100
Received: from localhost (saprar@localhost) by thor.cf.ac.uk (8.8.8/8.6.12) 
          with SMTP id JAA32443 for <info-performer@sgi.com>;
          Thu, 7 May 1998 09:02:09 +0100 (BST)
Date: Thu, 7 May 1998 09:02:09 +0100 (BST)
From: Roy Ruddle <Ruddle@cardiff.ac.uk>
Reply-To: Ruddle@cardiff.ac.uk
To: info-performer@sgi.com
Subject: Cleaning up data pools
Message-ID: <Pine.OSF.3.95q.980507085121.30256B-100000@thor>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

Hi there,

I think this is caused by something that I am neglecting to do.

I'm getting pfutil*.pfdpool files created in /usr/tmp and they
aren't deleted when I exit from my Performer application in a controlled
fashion. Calls within my application include:

  pfuInitInput( pw, PFUINPUT_X );

  do { // Main simulation loop
    pfuGetEvents( &events );
    pfuGetMouse( &mouse );

    ... etc.
  } while( !end );

  pfuExitInput();


Can anyone tell me what I should do to clean up the data pool files when I
exit my app?

many thanks

roy

------------------------------------------------------------------------
Roy Ruddle, Senior Research Associate
Cardiff Virtual Environment Laboratory
School of Psychology, Cardiff University, PO Box 901, Cardiff CF1 3YG
Tel: +44 (0) 1222 874000 x5030, Fax: +44 (0) 1222 874858
Email: Ruddle@CARDIFF.AC.UK     http://www.cf.ac.uk/uwc/psych/ruddle/

=======================================================================
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 May  7 02:23:48 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id CAA04509 for info-performer-dist@holodeck.engr.sgi.com; Thu, 7 May 1998 02:16: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 CAA04482 for <info-performer@holodeck.engr.sgi.com>; Thu, 7 May 1998 02:16: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 CAA21541044
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 7 May 1998 02:16:41 -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 CAA23954
	for <info-performer@sgi.com>; Thu, 7 May 1998 02:16:40 -0700 (PDT)
	mail_from (joaquim@rocketmail.com)
Message-ID: <19980507091309.6459.rocketmail@attach1.rocketmail.com>
Received: from [194.65.248.232] by attach1; Thu, 07 May 1998 02:13:09 PDT
Date: Thu, 7 May 1998 02:13:09 -0700 (PDT)
From: Joaquim Muchaxo <joaquim@rocketmail.com>
Reply-To: joaquim@imersiva.ch
Subject: X Crashes applying ClipTex. to gsets in Scene-G.
To: info-performer@sgi.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

Hi,
I have a inventor file that I converted to pfb with
pfconv. 
The file has gsets that may be used by multiple
LODs (ie one gset may be used by two LOD children)

I apply a cliptexture to all gsets in the scene-graph
successfully. However sometimes the aplication crashes
the X window manager.

I have removed the traversal that aplies the gstate
to every gset and it does not crash.
I have attached the source code. Would you help
me to debug it ?

Note: Neither of the versions in geoset_apply_geostate
(commented and uncommented) are crash free.

Best Regards,
Joaquim

---------------------------------------
void geoset_apply_geostate( pfGeoSet *GeoSet, pfGeoState *
gstate) { 
/*
  pfGeoState *gs = pfGetGSetGState(GeoSet);
  
  if( !gs)
    printf("no gstate"); 
    
  if( pfGetGStateAttr(gs, PFSTATE_TEXTURE) == ct ) {
    printf("gstate already has a cliptexture"); 
    return;
  }  
      
  pfGStateMode(gs, PFSTATE_ENTEXTURE, PF_ON);
  pfGStateAttr(gs, PFSTATE_TEXTURE, ct);
  pfGStateMode(gs, PFSTATE_ENLIGHTING, PF_ON); 
*/  

  pfGSetGState( GeoSet, NULL);  /* to remove current
gstate*/
  pfGSetGState( GeoSet, (pfGeoState *)gstate );  
}


void traverse_nodes( pfNode *node, process_node_fn todo,  
      void *data) {
  int	i, n;

  if (node == NULL || todo==NULL) {
    printf("traverse_nodes: node or 'to do' function is   
NULL");
    return;
  }
 
  if( !todo( node, data) )
    return; /* prune traversal */        

  if (pfIsOfType(node, pfGetGroupClassType())) {
  
    n = pfGetNumChildren((pfGroup *)node);					
    for (i = 0; i < n; i++)
      traverse_nodes( pfGetChild( (pfGroup *)node, i),
todo,         data );
  }   
    /* other type, such as light, prune traversal */	  
}



main () {


    ct = pfdLoadClipTexture(ClipTexFileName);
    Shared->mpcliptex = pfNewMPClipTexture();

    pfMPClipTextureClipTexture(Shared->mpcliptex, ct);
    (void)pfuAddMPClipTextureToPipes(Shared->mpcliptex,
pfGetPipe(0), NULL);

......
/* set up geo state */
    GeoState = pfNewGState(arena);
    pfGStateMode(GeoState, PFSTATE_ENTEXTURE, PF_ON);
    pfGStateAttr(GeoState, PFSTATE_TEXTURE, ct); 
    pfGStateMode(GeoState, PFSTATE_ENLIGHTING, PF_ON);

.......

if( TerrainFileName)
      Shared->terrain= pfdLoadFile( TerrainFileName ); 
      
  if( Shared->terrain) {          
    pfAddChild(root, Shared->terrain);      
    traverse_nodes( Shared->terrain, geode_apply_geostate,
        GeoState);  
  }  
......
}



===
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





_________________________________________________________
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  Thu May  7 07:42:25 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA05368 for info-performer-dist@holodeck.engr.sgi.com; Thu, 7 May 1998 07:22: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 HAA05341 for <info-performer@holodeck.engr.sgi.com>; Thu, 7 May 1998 07:22: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 HAA21201975;
	Thu, 7 May 1998 07:22:03 -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 HAA02693; Thu, 7 May 1998 07:22:00 -0700 (PDT)
	mail_from (amit@discreet.com)
Received: from cuba by helios.Discreet.QC.CA
	id KAA26140; Thu, 7 May 1998 10:21:44 -0400
Errors-To: postmaster@discreet.com
Received: from burkina (burkina [172.16.100.134]) by cuba (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA01675 for <info-performer@sgi.com>; Thu, 7 May 1998 10:21:56 -0400
From: amit@discreet.com (Amit Parghi)
Received: (from amit@localhost) by burkina (950413.SGI.8.6.12/) id KAA03370 for info-performer@sgi.com; Thu, 7 May 1998 10:21:56 -0400
Date: Thu, 7 May 1998 10:21:56 -0400
Message-Id: <9805071021.ZM3369@burkina>
In-Reply-To: "Marcus Barnes" <marcus@multigen.com>
        "Re: Performer 2.2 "compat" libraries ineffective?" (May  4,  1:32pm)
References: <199805011614.LAA05725@impact13.ncsa.uiuc.edu> 
	<9805041332.ZM9033@logan.engr.multigen.com>
Reply-To: amit@discreet.com (Amit Parghi)
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: info-performer@sgi.com
Subject: Re: Performer 2.2 "compat" libraries ineffective?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On May 1, 11:14am, Stuart Levy wrote:
>(2) Still, these apps lose material properties (color and transparency)
>    on objects they display, i.e., simple colored objects are rendered
>    as opaque gray (probably actually white).

I just wanted mention that we've seen the same thing here. Our app is built
with Performer 2.1, and running it on a system with the "compatibility"
libraries from 2.2 produced exactly this result: the shaded and lit parts
of the scene were reduced from shaded colours to shades of grey. That's
kind of a showstopper for an on-air television application.

On May 4,  1:32pm, Marcus Barnes wrote:
> The performer_eoe.compat subsytem DSO's, as shipped with Performer 2.2,
> are BROKEN as described above. They are unusable.

I'd say this is a pretty good summary of the situation.

Amit
--
      amit parghi                                         ten duke street
   amit@discreet.com                                       montreal, qc
    +1.514.393.1616            *discreet logic            h3c 2l7  canada
=======================================================================
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 May  7 10:07:11 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA06008 for info-performer-dist@holodeck.engr.sgi.com; Thu, 7 May 1998 09:55:35 -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 JAA05981 for <info-performer@holodeck.engr.sgi.com>; Thu, 7 May 1998 09:55:34 -0700
Received: (from gischer@localhost) by puget.engr.sgi.com (980205.SGI.8.8.8/960327.SGI.AUTOCF) id JAA06847; Thu, 7 May 1998 09:55:34 -0700 (PDT)
Date: Thu, 7 May 1998 09:55:34 -0700 (PDT)
Message-Id: <199805071655.JAA06847@puget.engr.sgi.com>
From: Jay Gischer <gischer@puget.engr.sgi.com>
To: lelkins@zeus.lnk.com (Les Elkins)
cc: info-performer@puget.engr.sgi.com
Subject: STL and Performer?
In-Reply-To: <9805062000.AA09370@zeus.lnk.com>
References: <9805062000.AA09370@zeus.lnk.com>
Status: O


Les Elkins writes:
 > Hello,
 > 
 > Are there any issues involved in using the Standard Template
 > Library with Performer? I've spliced some code into Perfly
 > that declares a pretty simple vector<int> x, but dies at
 > runtime with the following unresolved symbols:
 > 
 >  4248:perfly: rld: Error: unresolvable symbol in perfly: 
 > __node_allocator_lock__45__default_alloc_template__pt__13_XCiL11XCiL10
 >  4248:perfly: rld: Error: unresolvable symbol in perfly: 
 > free_list__45__default_alloc_template__pt__13_XCiL11XCiL10
 > 
 > This happens first thing at run time. The function containing 
 > the vector isn't yet called, the mere existance of the vector
 > causes the problems. When I create a simple test program with 
 > a vector and compile using CC, things work fine. Is there some 
 > makefile/compiler voodo I need to change in the 'perfly' Makefile?
 > 
 > I'm using the 'perfly' Makefile, running with C++ 7.1, 
 > IRIX 6.4 on an Octane, and looks to be Performer 2.1. I'm
 > getting the same results compiling with PFSTYLE set to 
 > 32, N32, and 64.
 > 
 > Any suggestions would be most appreciated...
 > 
What the message means is that certain symbols from STL didn't get
instantiated correctly during your build.  My suspicion is that this
occurs because "cc" is used to link perfly instead of "CC".  But
that's just a guess.  It's also possible that you are running against
DSO's that are different than the ones you are linking against.

Here's how to tell:
Short version:
% printenv | grep LD_LIBRARY*_PATH
% printenv | grep RLD

Longer version:
% setenv _RLD_PATH /usr/lib/rld.debug
<or> 
% setenv _RLDN32_PATH /usr/lib32/rld.debug

then
% setenv _RLD_ARGS -v
% perfly <args>

You will get a list of dso's loaded against perfly and then other
gunk printed to the tty.

------------------------------------------------------------------------
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 May  7 14:27:38 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA07004 for info-performer-dist@holodeck.engr.sgi.com; Thu, 7 May 1998 14:00: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 OAA06977 for <info-performer@holodeck.engr.sgi.com>; Thu, 7 May 1998 14:00: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 OAA21575497
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 7 May 1998 14:00:30 -0700 (PDT)
Received: from holodeck.gsfc.nasa.gov (holodeck.gsfc.nasa.gov [128.183.33.128]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id OAA21530
	for <info-performer@sgi.com>; Thu, 7 May 1998 14:00:28 -0700 (PDT)
	mail_from (maher@holodeck.gsfc.nasa.gov)
Received: (from maher@localhost) by holodeck.gsfc.nasa.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA14538; Thu, 7 May 1998 17:00:27 -0400
From: maher@holodeck.gsfc.nasa.gov (Stephen Maher)
Message-Id: <199805072100.RAA14538@holodeck.gsfc.nasa.gov>
Subject: Clipfly hangs Onyx2
To: info-performer@sgi.com
Date: Thu, 7 May 1998 17:00:27 -0400 (EDT)
Cc: maher@holodeck.gsfc.nasa.gov (Stephen Maher)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Status: O

Hi,

Already called this one in to SGI (case 0942235), but thought I'd check the
list. (btw, Mountainview reproduced this problem on their Onyx2)

We've been modifying clipfly and every so often it totally jams our Onyx2
IR - requiring a power cycle.

Turns out that the vanilla 2.2 MR clipfly, with a MR dataset, also flunks.

Running 

clipfly /usr/share/Performer/data/sample.spherepatch

repeatedly will hang THE ENTIRE MACHINE after, oh, 3 to 15 times.  Power
cycling required.

AFAIK, we've got pertinent patches.

Any tips?

Thanks,

Steve
--
stephen.maher@gsfc.nasa.gov (301) 286-3368  fax:(301) 286-1776
http://holodeck.gsfc.nasa.gov/vr/vr.html
NASA Goddard Space Flight Center
=======================================================================
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 May  7 15:11:49 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA07310 for info-performer-dist@holodeck.engr.sgi.com; Thu, 7 May 1998 14:44:13 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id OAA07283 for <info-performer@holodeck.engr.sgi.com>; Thu, 7 May 1998 14:44: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 OAA21592206
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 7 May 1998 14:44:10 -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 OAA09113
	for <info-performer@sgi.com>; Thu, 7 May 1998 14:44:09 -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 OAA26268; Thu, 7 May 1998 14:44:08 -0700 (PDT)
From: "Rob Jenkins" <robj@quid.engr.sgi.com>
Message-Id: <9805071444.ZM26934@quid.engr.sgi.com>
Date: Thu, 7 May 1998 14:44:08 -0700
In-Reply-To: maher@holodeck.gsfc.nasa.gov (Stephen Maher)
        "Clipfly hangs Onyx2" (May  7,  5:00pm)
References: <199805072100.RAA14538@holodeck.gsfc.nasa.gov>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: info-performer@sgi.com, maher@holodeck.gsfc.nasa.gov (Stephen Maher)
Subject: Re: Clipfly hangs Onyx2
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

Stephen

Looking at the case notes it's not obvious if you've been asked to upgrade your
Onyx2 gfx patch yet. I see one ref to a stack trace that suggests that you have
patch 2326 installed, if that is still the case then you need to upgrade that
to the latest patch 2922: Onyx2 6.4 graphics rollup #5 including GVO support.
I'll add notes to the support case to check this too.

Cheers
Rob

On May 7,  5:00pm, Stephen Maher wrote:
> Subject: Clipfly hangs Onyx2
> Hi,
>
> Already called this one in to SGI (case 0942235), but thought I'd check the
> list. (btw, Mountainview reproduced this problem on their Onyx2)
>
> We've been modifying clipfly and every so often it totally jams our Onyx2
> IR - requiring a power cycle.
>
> Turns out that the vanilla 2.2 MR clipfly, with a MR dataset, also flunks.
>
> Running
>
> clipfly /usr/share/Performer/data/sample.spherepatch
>
> repeatedly will hang THE ENTIRE MACHINE after, oh, 3 to 15 times.  Power
> cycling required.
>
> AFAIK, we've got pertinent patches.
>
> Any tips?
>
> Thanks,
>
> Steve
> --
> stephen.maher@gsfc.nasa.gov (301) 286-3368  fax:(301) 286-1776
> http://holodeck.gsfc.nasa.gov/vr/vr.html
> NASA Goddard Space Flight Center
> =======================================================================
> 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
>-- End of excerpt from Stephen Maher



-- 
________________________________________________________________
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 May  8 02:21:19 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id CAA01851 for info-performer-dist@holodeck.engr.sgi.com; Fri, 8 May 1998 02:02: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 CAA01824 for <info-performer@holodeck.engr.sgi.com>; Fri, 8 May 1998 02:02: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 CAA21138163
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 8 May 1998 02:02:16 -0700 (PDT)
Received: from server.rtset.co.il (FW-RTset.ser.netvision.net.il [199.203.166.198]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id CAA09039
	for <info-performer@sgi.com>; Fri, 8 May 1998 02:02:13 -0700 (PDT)
	mail_from (rany@rtset.co.il)
Received: from rtset.co.il (ts012p14.hrz.netvision.net.il [194.90.11.232]) by server.rtset.co.il (8.6.12/8.6.9) with ESMTP id KAA27951; Thu, 8 May 1997 10:51:00 +0200
Message-ID: <3552C9A3.54662C27@rtset.co.il>
Date: Fri, 08 May 1998 12:00:19 +0300
From: Ran Yakir <rany@rtset.co.il>
Reply-To: rany@rtset.co.il
Organization: RT-Set
X-Mailer: Mozilla 4.05 [en] (Win95; I)
MIME-Version: 1.0
To: Rob Jenkins <robj@quid.engr.sgi.com>
CC: info-performer@sgi.com, Stephen Maher <maher@holodeck.gsfc.nasa.gov>
Subject: Re: Clipfly hangs Onyx2
References: <199805072100.RAA14538@holodeck.gsfc.nasa.gov> <9805071444.ZM26934@quid.engr.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Stephen,

I had the same problem with cliptextures hanging the Onyx2. The 2/98 patch set has
solved it for me. I haven't installed the gfx patch. Rather, it was the kernel
rollup that helped.

Ran

Rob Jenkins wrote:

> Stephen
>
> Looking at the case notes it's not obvious if you've been asked to upgrade your
> Onyx2 gfx patch yet. I see one ref to a stack trace that suggests that you have
> patch 2326 installed, if that is still the case then you need to upgrade that
> to the latest patch 2922: Onyx2 6.4 graphics rollup #5 including GVO support.
> I'll add notes to the support case to check this too.
>
> Cheers
> Rob
>
> On May 7,  5:00pm, Stephen Maher wrote:
> > Subject: Clipfly hangs Onyx2
> > Hi,
> >
> > Already called this one in to SGI (case 0942235), but thought I'd check the
> > list. (btw, Mountainview reproduced this problem on their Onyx2)
> >
> > We've been modifying clipfly and every so often it totally jams our Onyx2
> > IR - requiring a power cycle.
> >
> > Turns out that the vanilla 2.2 MR clipfly, with a MR dataset, also flunks.
> >
> > Running
> >
> > clipfly /usr/share/Performer/data/sample.spherepatch
> >
> > repeatedly will hang THE ENTIRE MACHINE after, oh, 3 to 15 times.  Power
> > cycling required.
> >
> > AFAIK, we've got pertinent patches.
> >
> > Any tips?
> >
> > Thanks,
> >
> > Steve
> > --
> > stephen.maher@gsfc.nasa.gov (301) 286-3368  fax:(301) 286-1776
> > http://holodeck.gsfc.nasa.gov/vr/vr.html
> > NASA Goddard Space Flight Center
> > =======================================================================
> > 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
> >-- End of excerpt from Stephen Maher
>
> --
> ________________________________________________________________
> 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



--
 __                                  | Ran Yakir
 /_)  _  __   \  / _   / o __        | 28 Ben Gurion St.
/ )_ (_(_) )   \/ (_(_/<_(_)(        | Hod Hasharon 54200
              _/                     | Israel
-------------------------------------+--------------------------------
At Home :                            | At Work :
                                     |   RT-SET
  Voice  : +972-9-7489974            |   Voice  : +972-9-9552236
  Fax    : +972-9-7422149            |   Fax    : +972-9-9552239
  E-mail : rany@netvision.net.il     |   E-mail : rany@rtset.co.il
http://rtset.co.il/rany


=======================================================================
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 May  8 04:06:44 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id DAA02111 for info-performer-dist@holodeck.engr.sgi.com; Fri, 8 May 1998 03:37:28 -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 DAA02084 for <info-performer@holodeck.engr.sgi.com>; Fri, 8 May 1998 03:37: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 DAA18395179
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 8 May 1998 03:37:26 -0700 (PDT)
Received: from ligsg25.epfl.ch (ligsg25.epfl.ch [128.178.78.34]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id DAA27105
	for <info-performer@sgi.com>; Fri, 8 May 1998 03:37:24 -0700 (PDT)
	mail_from (aubel@lig.di.epfl.ch)
Received: by ligsg25.epfl.ch (Smail3.1.29.1 #28)
	id m0yXkX3-002xayC; Fri, 8 May 98 12:37 MDT
From: "Amaury Aubel" <aubel@lig.di.epfl.ch>
Message-Id: <9805081237.ZM4869@lig.di.epfl.ch>
Date: Fri, 8 May 1998 12:37:37 -0600
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: info-performer@sgi.com
Subject: Max. number of textures
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

Hi all,

a quick one:
Is there any restrictions concerning the number of textures in a scene?



Amaury.
=======================================================================
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 May  8 08:54:01 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id IAA02805 for info-performer-dist@holodeck.engr.sgi.com; Fri, 8 May 1998 08:42: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 IAA02778 for <info-performer@holodeck.engr.sgi.com>; Fri, 8 May 1998 08:42: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 IAA22233952
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 8 May 1998 08:42:40 -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 IAA25446
	for <info-performer@sgi.com>; Fri, 8 May 1998 08:42:38 -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 KAA00958 for <info-performer@sgi.com>; Fri, 8 May 1998 10:42:37 -0500 (CDT)
Date: Fri, 8 May 1998 10:41:25 -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: Finding addresses.
Message-ID: <Pine.SGI.3.96.980508102239.11922A-100000@sutcliffe.bgm.link.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O



If I load an object into Performer in the DBASE task,
and then do a pfMergeBuffer to incorporate it into
the main scene graph, how do I find the address of
that same object as it appears in (say) APP ?

In the past, I connected user data to the object
and used the pfCopyFunc callback to find the new
copy of the object.

I now realise that this should never have worked (although
it did work - right up to the very last beta prior to
Perf 2.2 MR). Now it fails miserably - presumably
because the pfCopyFunc callback is also copying the
data into CULL/ISECT/whatever - and I can't tell
which address is the right one for APP.

There has to be a better way to do this - but I can't
think what it is.

I need to do this for many reasons - here is an
example: Suppose  my database loader (DBASE task)
knows (from something in the file I'm loading)
that it has to create a pfDCS which is required to
rotate at 10 degrees per second. DBASE knows the
address of the pfDCS in it's pfBuffer prior to the
pfMergeBuffer. However, in frames after the pfMergeBuffer, 
the APP process needs to know the address of that
pfDCS so it can call pfDCSRot each frame with
appropriately increasing angles.

Unfortunately I can't just pass the address that DBASE
has into the APP process since it was in a different
pfBuffer.

I suppose I could attach some kind of unique tag onto
that new DCS and then walk the scene graph in APP
searching for that tag. However, in the large scene
graphs I have, that would be pretty time-consuming.

Anyway, this is a very specific example and I need
a very general solution to passing object addresses
between processes.

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  Fri May  8 09:54:19 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA03030 for info-performer-dist@holodeck.engr.sgi.com; Fri, 8 May 1998 09:38:53 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA03003 for <info-performer@holodeck.engr.sgi.com>; Fri, 8 May 1998 09:38: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 JAA22350243
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 8 May 1998 09:38:50 -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 JAA20175
	for <info-performer@sgi.com>; Fri, 8 May 1998 09:38:48 -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 LAA03530 for <info-performer@sgi.com>; Fri, 8 May 1998 11:38:47 -0500 (CDT)
Date: Fri, 8 May 1998 11:37:36 -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: Re: Finding addresses.
Message-ID: <Pine.SGI.3.96.980508113505.12195A-100000@sutcliffe.bgm.link.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O


...I forgot to mention the critical information that I'm using a
mixture of pfBufferAddChild and pfBufferClone commands to attach
library objects into the tree prior to pfMergeBuffer.


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 May  8 10:13:27 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA03092 for info-performer-dist@holodeck.engr.sgi.com; Fri, 8 May 1998 09:59:27 -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 JAA03065 for <info-performer@holodeck.engr.sgi.com>; Fri, 8 May 1998 09:59: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 JAA22238406
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 8 May 1998 09:59:24 -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 JAA29267
	for <info-performer@sgi.com>; Fri, 8 May 1998 09:59:22 -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 LAA01194; Fri, 8 May 1998 11:47:10 -0500
Sender: mew@paradigmsim.com
Message-ID: <3553370D.41C6@paradigmsim.com>
Date: Fri, 08 May 1998 11:47:09 -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: Amaury Aubel <aubel@lig.di.epfl.ch>
CC: info-performer@sgi.com
Subject: Re: Max. number of textures
References: <9805081237.ZM4869@lig.di.epfl.ch>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

In the past, the GL has had limits.  For instance, on Onyx
RealityEngine2 the GL has a static table for 512 textures.

-- mew


Amaury Aubel wrote:
> 
> Hi all,
> 
> a quick one:
> Is there any restrictions concerning the number of textures in a scene?
> 
> Amaury.

-- 
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  Fri May  8 11:47:27 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA03982 for info-performer-dist@holodeck.engr.sgi.com; Fri, 8 May 1998 11:34:37 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA03955 for <info-performer@holodeck.engr.sgi.com>; Fri, 8 May 1998 11:34: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 LAA22250991
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 8 May 1998 11:34:35 -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 LAA13673
	for <info-performer@sgi.com>; Fri, 8 May 1998 11:34:34 -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 OAA03797
	for <@bnl.gov:info-performer@sgi.com>; Fri, 8 May 1998 14:34:33 -0400 (EDT)
Received: by sirius.ccd.bnl.gov (950215.SGI.8.6.10/940406.SGI.AUTO)
	for info-performer@sgi.com id OAA21539; Fri, 8 May 1998 14:34:32 -0400
From: "A. Ballard Andrews" <ballard@sirius.ccd.bnl.gov>
Message-Id: <9805081434.ZM21537@sirius.ccd.bnl.gov>
Date: Fri, 8 May 1998 14:34:32 -0400
X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail)
To: info-performer@sgi.com
Subject: image quality
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

Hello Performers,

Why do large RGB images look good in Performer
(perfly) but crummy in Inventor (ivview)?

A. 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  Fri May  8 12:06:33 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA04100 for info-performer-dist@holodeck.engr.sgi.com; Fri, 8 May 1998 12:00: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 MAA04072 for <info-performer@holodeck.engr.sgi.com>; Fri, 8 May 1998 12:00: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 MAA22220910
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 8 May 1998 12:00:15 -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 MAA24602
	for <info-performer@sgi.com>; Fri, 8 May 1998 12:00:14 -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 MAA29448; Fri, 8 May 1998 12:00:09 -0700 (PDT)
From: "Rob Jenkins" <robj@quid.engr.sgi.com>
Message-Id: <9805081200.ZM29483@quid.engr.sgi.com>
Date: Fri, 8 May 1998 12:00:08 -0700
In-Reply-To: "A. Ballard Andrews" <ballard@sirius.ccd.bnl.gov>
        "image quality" (May  8,  2:34pm)
References: <9805081434.ZM21537@sirius.ccd.bnl.gov>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: "A. Ballard Andrews" <ballard@sirius.ccd.bnl.gov>, info-performer@sgi.com
Subject: Re: image quality
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On May 8,  2:34pm, A. Ballard Andrews wrote:
> Subject: image quality
> Hello Performers,
>
> Why do large RGB images look good in Performer
> (perfly) but crummy in Inventor (ivview)?
>
> A. Andrews
> =======================================================================
> 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 A. Ballard Andrews

Inventor has an SoComplexity node ( see the man page for that node ) which has
a
'textureQuality' field. textureQuality defaults to 0.5, try adding a complexity
node before any texture2 nodes in your iv file and setting textureQuality to
one ( or at least > 0.8 should be better I think ) and see if ivview looks
better, so like:

	Complexity {
	    type	~
	    value	~
	    textureQuality	1.0
	}
	Texture2 {
....

Also, if you're on Impact or OCTANE then you might be seeing a known thing
where Inventor uses MAX_TEXTURE_SIZE to see if a texture fits in TRAM, if it
doesn't then it shrinks it so you lose something in the filtering. This isn't
ideal and there's a way round it but it might not be what you describe, I can
give you more detail if it is.

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 May  8 12:09:48 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA04220 for info-performer-dist@holodeck.engr.sgi.com; Fri, 8 May 1998 12:08: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 MAA04193 for <info-performer@holodeck.engr.sgi.com>; Fri, 8 May 1998 12:08: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 MAA22305436
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 8 May 1998 12:08:58 -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 MAA28763
	for <info-performer@sgi.com>; Fri, 8 May 1998 12:08:57 -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 MAA29377; Fri, 8 May 1998 12:08:52 -0700 (PDT)
From: "Rob Jenkins" <robj@quid.engr.sgi.com>
Message-Id: <9805081208.ZM29499@quid.engr.sgi.com>
Date: Fri, 8 May 1998 12:08:51 -0700
In-Reply-To: Mike Weiblen <mew@paradigmsim.com>
        "Re: Max. number of textures" (May  8, 11:47am)
References: <9805081237.ZM4869@lig.di.epfl.ch>  <3553370D.41C6@paradigmsim.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Mike Weiblen <mew@paradigmsim.com>, Amaury Aubel <aubel@lig.di.epfl.ch>
Subject: Re: Max. number of textures
Cc: info-performer@sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

I'm not sure if there are any hard limits on other machines ( I don't think so
for iR at least ) but suffice to say that if you have that kind of number of
different textures then you'll be incurring a lot of transform overhead from
texture binds. The GL perf benchmarks give you a measure of how number and size
of textures effects texture performance, try www.specbench.org I'll try to find
if SGI publishes GLperf results externally anywhere.
For a 2Rm Onyx2 iR some things to note are:

o Texture loads are more efficient for larger textures, loading lots of small
textures takes longer than loading the same number of texels in one large
texture.

o Switching between mipmapped textures is much more expensive than switching
between non-mipmapped textures.

Cheers
Rob

On May 8, 11:47am, Mike Weiblen wrote:
> Subject: Re: Max. number of textures
> In the past, the GL has had limits.  For instance, on Onyx
> RealityEngine2 the GL has a static table for 512 textures.
>
> -- mew
>
>
> Amaury Aubel wrote:
> >
> > Hi all,
> >
> > a quick one:
> > Is there any restrictions concerning the number of textures in a scene?
> >
> > Amaury.
>
> --
> 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
>-- End of excerpt from Mike Weiblen



-- 
________________________________________________________________
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 May  8 13:14:54 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA04638 for info-performer-dist@holodeck.engr.sgi.com; Fri, 8 May 1998 12:54: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 MAA04611 for <info-performer@holodeck.engr.sgi.com>; Fri, 8 May 1998 12:54: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 MAA21309019
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 8 May 1998 12:54: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 MAA16284
	for <info-performer@sgi.com>; Fri, 8 May 1998 12:54:42 -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 NAA29123 for <info-performer@sgi.com>; Fri, 8 May 1998 13:05:45 -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 TAA29323 for <@plateau.engr.multigen.com:info-performer@sgi.com>; Fri, 8 May 1998 19:55:56 GMT
Received: (from marcus@localhost) by logan.engr.multigen.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA02147 for info-performer@sgi.com; Fri, 8 May 1998 12:55:54 -0700
From: "Marcus Barnes" <marcus@multigen.com>
Message-Id: <9805081255.ZM2145@logan.engr.multigen.com>
Date: Fri, 8 May 1998 12:55:54 -0700
In-Reply-To: "Rob Jenkins" <robj@quid.engr.sgi.com>
        "Re: Max. number of textures" (May  8, 12:08pm)
References: <9805081237.ZM4869@lig.di.epfl.ch>  <3553370D.41C6@paradigmsim.com> 
	<9805081208.ZM29499@quid.engr.sgi.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: Max. number of textures
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On May 8, 12:08pm, Rob Jenkins wrote:
>I'm not sure if there are any hard limits on other machines ( I don't think so
>for iR at least )

There is always a hard limit to such things. Somewhere in the hardware is a
 register of say 9 or 16 bits that is used to index (or point to) individual
textures. So the limit on the number of items is 512 or 64k for example.

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-4103       +
=======================================================================
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 May  8 14:28:09 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA05221 for info-performer-dist@holodeck.engr.sgi.com; Fri, 8 May 1998 14:04: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 OAA05194 for <info-performer@holodeck.engr.sgi.com>; Fri, 8 May 1998 14:04: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 OAA22092533
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 8 May 1998 14:04:39 -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 OAA18348
	for <info-performer@sgi.com>; Fri, 8 May 1998 14:04:38 -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 OAA22351745;
	Fri, 8 May 1998 14:04:37 -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 OAA09126; Fri, 8 May 1998 14:04:27 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <3553735B.7979B457@sgi.com>
Date: Fri, 08 May 1998 14:04:27 -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@sgi.com
Subject: Re: Max. number of textures
References: <9805081237.ZM4869@lig.di.epfl.ch>  <3553370D.41C6@paradigmsim.com> 
		<9805081208.ZM29499@quid.engr.sgi.com> <9805081255.ZM2145@logan.engr.multigen.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Marcus Barnes wrote:
> 
> On May 8, 12:08pm, Rob Jenkins wrote:
> >I'm not sure if there are any hard limits on other machines ( I don't think so
> >for iR at least )
> 
> There is always a hard limit to such things. Somewhere in the hardware is a
>  register of say 9 or 16 bits that is used to index (or point to) individual
> textures. So the limit on the number of items is 512 or 64k for example.
>

Well even if there is a smaller hardware limit an OpenGL
implementation should be able to handle any number working
around the hardware implementation, the handle is an unsigned
integer which should give 2^32 unique handles before you have
to do anything smart at the application level so I don't
think you'll be running into any limit soon.

Cheers,Angus.
=======================================================================
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 May  8 14:28:18 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA05192 for info-performer-dist@holodeck.engr.sgi.com; Fri, 8 May 1998 14:03: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 OAA05165 for <info-performer@holodeck.engr.sgi.com>; Fri, 8 May 1998 14:03: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 OAA12899660
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 8 May 1998 14:03:12 -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 OAA17848
	for <info-performer@sgi.com>; Fri, 8 May 1998 14:03:11 -0700 (PDT)
	mail_from (kishore@aimnet.com)
Received: (from kishore@localhost)
	by aimnet.com (8.8.8/8.8.6) id OAA09626
	for info-performer@sgi.com; Fri, 8 May 1998 14:00:21 -0700 (PDT)
Date: Fri, 8 May 1998 14:00:21 -0700 (PDT)
From: Anita Kishore <kishore@aimnet.com>
Message-Id: <199805082100.OAA09626@aimnet.com>
To: info-performer@sgi.com
Subject: derived classes from performer nodes
Status: O


Hi:

	Can someone tell me if the foll. derivation is valid in
performer (version 2.2):

	class XXX : public pfDCS, public YYY
	{

		public:
		    XXX() {}
		    virtual ~XXX() {}

	}

	class YYY
	{
	    	public :
		    YYY() {}
		    virtual ~YYY() {}
	}

I am having trouble deleting the scene graph containing a node of type
XXX in the DBASE process. My program crashes with dbx showing the crash
at "virtual ~XXX() {}" in the call to 'realfree()'. Purify gives
FMM (freeing mismatched memory) at this line. I haven't overriden the
'new' and 'delete' operator for class XXX coz' it will anyway be 
allocated in shared memory due to pfDCS as its parent , so the DBASE
process should be able to access its instance. The actual program is
based on the above class hierarchy with some data members which I make
sure are in shared arena (pfGetSharedArena()).

Thanks for any insight.
-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  Fri May  8 14:40:33 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA05477 for info-performer-dist@holodeck.engr.sgi.com; Fri, 8 May 1998 14:15: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 OAA05447 for <info-performer@holodeck.engr.sgi.com>; Fri, 8 May 1998 14:14: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 OAA22098801
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 8 May 1998 14:14:59 -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 OAA23829
	for <info-performer@sgi.com>; Fri, 8 May 1998 14:14:55 -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 OAA20373 for info-performer@sgi.com; Fri, 8 May 1998 14:23:36 -0700 (PDT)
From: Jan Barglowski <jan@archimedes.vislab.navy.mil>
Posted-Date: Fri, 8 May 1998 14:23:36 -0700 (PDT)
Message-Id: <199805082123.OAA20373@archimedes.vislab.navy.mil>
Subject: Alpha and anti-aliasing...
To: info-performer@sgi.com
Date: Fri, 8 May 1998 14:23:36 -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:

This is probably a really easy question to answer.  I have a cloud
texture that is in rgba format.  I texture it to a square and view
the file in perfly.  The texture looks to have 2 bits of alpha, unless
I turn off anti-aliasing!  Now, I don't want to turn off antialiasing
for my main app, so how do I solve this?

Vitals:
- Onyx iR
- Performer 2.2
- MultiGen 15.4 (still using MultiGen loader that came with Performer 2.2)

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  Fri May  8 15:23:15 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA09575 for info-performer-dist@holodeck.engr.sgi.com; Fri, 8 May 1998 14:58: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 OAA09518 for <info-performer@holodeck.engr.sgi.com>; Fri, 8 May 1998 14:58: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 OAA22522510
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 8 May 1998 14:58: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 OAA19694
	for <info-performer@sgi.com>; Fri, 8 May 1998 14:58: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 OAA20693620;
	Fri, 8 May 1998 14:58: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 OAA09215; Fri, 8 May 1998 14:57:50 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <35537FDE.CBEDD2D0@sgi.com>
Date: Fri, 08 May 1998 14:57:50 -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: Jan Barglowski <jan@archimedes.vislab.navy.mil>
CC: info-performer@sgi.com
Subject: Re: Alpha and anti-aliasing...
References: <199805082123.OAA20373@archimedes.vislab.navy.mil>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Jan Barglowski wrote:
> 
> Performers:
> 
> This is probably a really easy question to answer.  I have a cloud
> texture that is in rgba format.  I texture it to a square and view
> the file in perfly.  The texture looks to have 2 bits of alpha, unless
> I turn off anti-aliasing!  Now, I don't want to turn off antialiasing
> for my main app, so how do I solve this?
> 
> Vitals:
> - Onyx iR
> - Performer 2.2
> - MultiGen 15.4 (still using MultiGen loader that came with Performer 2.2)
> 

You are using the sub pixel alpha mask mode for order
invariant transparency.

This gives you number of samples +1 values of alpha so you
get 5 discrete shades including 0.0 and 1.0.

You have the option of using blended transparency instead
which will introduce the classic zbuffer alpha occlusion
problems unless you sort in the cull process.

To do this set the pfTransparency to PFTR_HIGH_QUALITY or
PFTR_BLEND_ALPHA.

You could also use more multisamples to increase the
number of multisamples and therefore the number of
shades of alpha.

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 May  8 15:41:13 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA14838 for info-performer-dist@holodeck.engr.sgi.com; Fri, 8 May 1998 15:29: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 PAA14811 for <info-performer@holodeck.engr.sgi.com>; Fri, 8 May 1998 15:29:37 -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 PAA22488455
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 8 May 1998 15:29:36 -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 PAA09363
	for <info-performer@sgi.com>; Fri, 8 May 1998 15:29:34 -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 PAA11913061;
	Fri, 8 May 1998 15:29:33 -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 PAA09288; Fri, 8 May 1998 15:29:30 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <3553874A.1497433E@sgi.com>
Date: Fri, 08 May 1998 15:29: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: Jan Barglowski <jan@archimedes.vislab.navy.mil>, info-performer@sgi.com
Subject: Re: Alpha and anti-aliasing...
References: <199805082123.OAA20373@archimedes.vislab.navy.mil> <35537FDE.CBEDD2D0@sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Angus Dorbie wrote:
> 
> Jan Barglowski wrote:
> >
> > Performers:
> >
> > This is probably a really easy question to answer.  I have a cloud
> > texture that is in rgba format.  I texture it to a square and view
> > the file in perfly.  The texture looks to have 2 bits of alpha, unless
> > I turn off anti-aliasing!  Now, I don't want to turn off antialiasing
> > for my main app, so how do I solve this?
> >
> > Vitals:
> > - Onyx iR
> > - Performer 2.2
> > - MultiGen 15.4 (still using MultiGen loader that came with Performer 2.2)
> >
> 
> You are using the sub pixel alpha mask mode for order
> invariant transparency.
> 
> This gives you number of samples +1 values of alpha so you
> get 5 discrete shades including 0.0 and 1.0.
> 
> You have the option of using blended transparency instead
> which will introduce the classic zbuffer alpha occlusion
> problems unless you sort in the cull process.
> 
> To do this set the pfTransparency to PFTR_HIGH_QUALITY or
> PFTR_BLEND_ALPHA.
> 

Note that you really need to do this in the geostate unless
you want to override it on for all transparency in which
case anywhere in the draw process will do.

Cheers,Angus.

> You could also use more multisamples to increase the
> number of multisamples and therefore the number of
> shades of alpha.
> 
> 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

-- 
"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 May  8 15:41:11 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA14707 for info-performer-dist@holodeck.engr.sgi.com; Fri, 8 May 1998 15:17: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 PAA14675 for <info-performer@holodeck.engr.sgi.com>; Fri, 8 May 1998 15:17: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 PAA21763235
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 8 May 1998 15:17:01 -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 PAA01926
	for <info-performer@sgi.com>; Fri, 8 May 1998 15:16:59 -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 PAA00610 for <info-performer@sgi.com>; Fri, 8 May 1998 15:28:01 -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 WAA03409 for <@plateau.engr.multigen.com:info-performer@sgi.com>; Fri, 8 May 1998 22:18:13 GMT
Received: (from marcus@localhost) by logan.engr.multigen.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA02485 for info-performer@sgi.com; Fri, 8 May 1998 15:18:12 -0700
From: "Marcus Barnes" <marcus@multigen.com>
Message-Id: <9805081518.ZM2483@logan.engr.multigen.com>
Date: Fri, 8 May 1998 15:18:12 -0700
In-Reply-To: Jan Barglowski <jan@archimedes.vislab.navy.mil>
        "Alpha and anti-aliasing..." (May  8,  2:23pm)
References: <199805082123.OAA20373@archimedes.vislab.navy.mil>
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: Alpha and anti-aliasing...
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On May 8,  2:23pm, Jan Barglowski wrote:
>The texture looks to have 2 bits of alpha, unless
>I turn off anti-aliasing!  Now, I don't want to turn off antialiasing
>for my main app, so how do I solve this?

Uhm ... so you want more bits for you alpha component?

In MultiGen, choose the texture and select "Edit->Modify Attributes". Choose an
"Internal Format" of TX_RGBA_4 or TX_RGBA_8 ... for example. Select "Save".

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-4103       +
=======================================================================
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 May  8 16:48:03 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA15344 for info-performer-dist@holodeck.engr.sgi.com; Fri, 8 May 1998 16:20: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 QAA15317 for <info-performer@holodeck.engr.sgi.com>; Fri, 8 May 1998 16:20: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 QAA20108268
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 8 May 1998 16:20:10 -0700 (PDT)
Received: from lobotomy.evt.com ([204.133.157.33]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id QAA04773
	for <info-performer@sgi.com>; Fri, 8 May 1998 16:20:06 -0700 (PDT)
	mail_from (herod@evt.com)
Received: from evt.com (localhost [127.0.0.1]) by lobotomy.evt.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA01851 for <info-performer@sgi.com>; Fri, 8 May 1998 17:20:04 -0600
Sender: herod@evt.com
Message-ID: <35539324.40D03077@evt.com>
Date: Fri, 08 May 1998 17:20:04 -0600
From: Scott Herod <herod@evt.com>
X-Mailer: Mozilla 4.04 [en] (X11; I; IRIX 6.3 IP32)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: Deleting textures in 2.0.x
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

I need to manually delete textures.  The following works (or appears
to) in 2.2.

    pfTexture *tex;
    tex->deleteGLHandle();   // For Performer 2.2

However pfObjects don't know that call in 2.0.4.  Is there something
similar that I can do in 2.0.4?  I've got a reference here to a call

    // _pfDeleteTexHandle(tex);    // For Performer 2.0.x

but can't find anything even similar.

Thank you,

Scott Herod
herod@evt.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 May  8 19:23:54 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id TAA20181 for info-performer-dist@holodeck.engr.sgi.com; Fri, 8 May 1998 19:06: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 TAA20154 for <info-performer@holodeck.engr.sgi.com>; Fri, 8 May 1998 19: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 TAA13401609
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 8 May 1998 19:06:01 -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 TAA08681
	for <info-performer@sgi.com>; Fri, 8 May 1998 19:06:00 -0700 (PDT)
	mail_from (allan@southpark.engr.sgi.com)
Received: from southpark.engr.sgi.com (southpark.engr.sgi.com [150.166.37.36])
	by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id TAA17751332
	for <@cthulhu.engr.sgi.com:info-performer@sgi.com>;
	Fri, 8 May 1998 19:05:59 -0700 (PDT)
Received: (from allan@localhost) by southpark.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) id TAA14684 for info-performer@sgi.com; Fri, 8 May 1998 19:05:59 -0700 (PDT)
Date: Fri, 8 May 1998 19:05:59 -0700 (PDT)
From: allan@southpark.engr.sgi.com (Allan Schaffer)
Message-Id: <9805081905.ZM20192@southpark.engr.sgi.com>
In-Reply-To: Jan Barglowski <jan@archimedes.vislab.navy.mil>
        "Alpha and anti-aliasing..." (May  8,  2:23pm)
References: <199805082123.OAA20373@archimedes.vislab.navy.mil>
X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail)
To: info-performer@sgi.com
Subject: Re: Alpha and anti-aliasing...
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On May 8,  2:23pm, Jan Barglowski wrote:
> This is probably a really easy question to answer.  I have a cloud
> texture that is in rgba format.  I texture it to a square and view
> the file in perfly.  The texture looks to have 2 bits of alpha, unless
> I turn off anti-aliasing!  Now, I don't want to turn off antialiasing
> for my main app, so how do I solve this?

Angus is correct about the transparency setting and Marcus about
texture; just to clarify the overall point you'll have to do both
things they say.

You're running into two of the places where Performer's default
behavior chooses 'fast' instead of 'high quality':  #1 with
transparency (when ms is enabled it uses subpixel alpha by default
instead of blending) and #2 with texture formats (textures are
reduced to 16 bits by default)

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 May  8 19:50:57 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id TAA20312 for info-performer-dist@holodeck.engr.sgi.com; Fri, 8 May 1998 19:37: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 TAA20285 for <info-performer@holodeck.engr.sgi.com>; Fri, 8 May 1998 19:37: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 TAA22388240
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 8 May 1998 19:37: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 TAA18743
	for <info-performer@sgi.com>; Fri, 8 May 1998 19:37:16 -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 TAA22564139
	for <@cthulhu.engr.sgi.com:info-performer@sgi.com>;
	Fri, 8 May 1998 19:37:16 -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 TAA09516; Fri, 8 May 1998 19:35:56 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <3553C10B.791D4745@sgi.com>
Date: Fri, 08 May 1998 19:35:55 -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: Allan Schaffer <allan@southpark.engr.sgi.com>
CC: info-performer@sgi.com
Subject: Re: Alpha and anti-aliasing...
References: <199805082123.OAA20373@archimedes.vislab.navy.mil> <9805081905.ZM20192@southpark.engr.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Allan Schaffer wrote:
> 
> On May 8,  2:23pm, Jan Barglowski wrote:
> > This is probably a really easy question to answer.  I have a cloud
> > texture that is in rgba format.  I texture it to a square and view
> > the file in perfly.  The texture looks to have 2 bits of alpha, unless
> > I turn off anti-aliasing!  Now, I don't want to turn off antialiasing
> > for my main app, so how do I solve this?
> 
> Angus is correct about the transparency setting and Marcus about
> texture; just to clarify the overall point you'll have to do both
> things they say.

Sorry, but the original poster mentioned that the problem
was solved when he disabled anti-aliasing. An important
clue meaning that he already has sufficient precision in
texture memory and the problem was entirely due to
multisample mask transparency, not internal texture
format.

> You're running into two of the places where Performer's default
> behavior chooses 'fast' instead of 'high quality':  #1 with
> transparency (when ms is enabled it uses subpixel alpha by default
> instead of blending) and #2 with texture formats (textures are
> reduced to 16 bits by default)

Yes but this gives 4 bits or 8 bits of precision (depending
on RGBA or IA components) which gives  16 or 256 shades of
alpha, not ~4.

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  Sat May  9 06:30:47 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id FAA21517 for info-performer-dist@holodeck.engr.sgi.com; Sat, 9 May 1998 05:58: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 FAA21489 for <info-performer@holodeck.engr.sgi.com>; Sat, 9 May 1998 05:58: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 FAA22646836
	for <info-performer@cthulhu.engr.sgi.com>;
	Sat, 9 May 1998 05:57:59 -0700 (PDT)
Received: from alpha.netvision.net.il (alpha.netvision.net.il [194.90.1.13]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id FAA05319; Sat, 9 May 1998 05:57:55 -0700 (PDT)
	mail_from (moshe@orad.co.il)
Received: from EFRAT.netvision.net.il (ts024p3.hrz.netvision.net.il [194.90.5.185])
	by alpha.netvision.net.il (8.8.6/8.8.6) with SMTP id PAA15633;
	Sat, 9 May 1998 15:56:15 +0300 (IDT)
Message-ID: <3554D102.1617@orad.co.il>
Date: Sat, 09 May 1998 14:56:19 -0700
From: Moshe Nissim <moshe@orad.co.il>
Reply-To: moshe@orad.co.il
Organization: Orad Hi-Tec Systems
X-Mailer: Mozilla 3.0 (Win16; I)
MIME-Version: 1.0
To: Angus Dorbie <dorbie@sgi.com>
CC: Jan Barglowski <jan@archimedes.vislab.navy.mil>, info-performer@sgi.com
Subject: Re: Alpha and anti-aliasing...
References: <199805082123.OAA20373@archimedes.vislab.navy.mil> <35537FDE.CBEDD2D0@sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Angus Dorbie wrote:

> You have the option of using blended transparency instead
> which will introduce the classic zbuffer alpha occlusion
> problems unless you sort in the cull process.
> 

Keep in mind that the cull process distance-based sorting is done
based on the objects' centers of their bounding spheres.  On the other
hand, zbuffer is pixel-based. So this sorting will work correctly
for some types of scenes, but not for others
(objects are small compared to inter-object
distances, no complex depth-interactions between objects, etc.)
Alas, the classic zbuffer alpha occlusion problem cannot be completely
solved on zbuffer-based rendering hw.


> You could also use more multisamples to increase the
> number of multisamples and therefore the number of
> shades of alpha.


But if you need framebuffer-alpha (not to be confused with 
material/object/texture alpha), don't try to increase the
 number of multisamples.
 
Bye,
Moshe

----------------------------------
Moshe Nissim
Orad Hi-Tec Systems
=======================================================================
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 May 10 14:19:51 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA23827 for info-performer-dist@holodeck.engr.sgi.com; Sun, 10 May 1998 14:00: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 OAA23800 for <info-performer@holodeck.engr.sgi.com>; Sun, 10 May 1998 14:00: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 OAA15558631
	for <info-performer@cthulhu.engr.sgi.com>;
	Sun, 10 May 1998 14:00: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 OAA07161
	for <info-performer@sgi.com>; Sun, 10 May 1998 14:00: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 OAA22152259;
	Sun, 10 May 1998 14:00:05 -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 NAA11220; Sun, 10 May 1998 13:59:54 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <3556154A.F9485F63@sgi.com>
Date: Sun, 10 May 1998 13:59:54 -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: moshe@orad.co.il
CC: Jan Barglowski <jan@archimedes.vislab.navy.mil>, info-performer@sgi.com
Subject: Re: Alpha and anti-aliasing...
References: <199805082123.OAA20373@archimedes.vislab.navy.mil> <35537FDE.CBEDD2D0@sgi.com> <3554D102.1617@orad.co.il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Moshe Nissim wrote:
> 
> Angus Dorbie wrote:
> 
> > You have the option of using blended transparency instead
> > which will introduce the classic zbuffer alpha occlusion
> > problems unless you sort in the cull process.
> >
> 
> Keep in mind that the cull process distance-based sorting is done
> based on the objects' centers of their bounding spheres.  On the other
> hand, zbuffer is pixel-based. So this sorting will work correctly
> for some types of scenes, but not for others
> (objects are small compared to inter-object
> distances, no complex depth-interactions between objects, etc.)
> Alas, the classic zbuffer alpha occlusion problem cannot be completely
> solved on zbuffer-based rendering hw.

This is right but not the whole picture, it's appropriate to
supply a little more detail:

The sorting in the cull process places all transparent geometry
(defined as those whose geostate pfTransparency isn't PFTR_OFF),
last in the display list. This isn't a range based test so you
have correct rendering of transparent scene content w.r.t. the
opaque scene.

This leaves you with only inter transparent occlusion, which must
then be depth sorted. This requires the application to modify the
channel bin sorting mechanism using a PFSORT_BACK_TO_FRONT token.
This will produce geoset level depth sorting of transparent objects.

Here from the manual page you can see the calls to set up opaque
geometry sorted by state for performance and the transparent
objects sorted by depth which may cause a few extra state changes.

chan->setBinSort(PFSORT_OPAQUE_BIN, PFSORT_BY_STATE, sortOrders);
chan->setBinSort(PFSORT_TRANSP_BIN, PFSORT_BACK_TO_FRONT, NULL);

This would also explain why turning sorting on might incur a few
extra state changes in some circumstances.

In addition you can then use pfAlphaFunc calls to limit the
scope of incorrect z buffer occlusion on objects like cookiecut
trees.

> 
> > You could also use more multisamples to increase the
> > number of multisamples and therefore the number of
> > shades of alpha.
> 
> But if you need framebuffer-alpha (not to be confused with
> material/object/texture alpha), don't try to increase the
>  number of multisamples.

Few people using performer actually use framebuffer or
destination alpha, and even fewer need to, but with destination
alpha in the visual (RGBA12) you are correct to point out
that on iR only 4 multisample visuals are supported.

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  Sun May 10 17:45:36 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id RAA24250 for info-performer-dist@holodeck.engr.sgi.com; Sun, 10 May 1998 17:17: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 RAA24223 for <info-performer@holodeck.engr.sgi.com>; Sun, 10 May 1998 17:17: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 RAA22014931
	for <info-performer@cthulhu.engr.sgi.com>;
	Sun, 10 May 1998 17:17:07 -0700 (PDT)
Received: from sse.co.jp (sirius.ip.sse.co.jp [210.130.177.1]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id RAA11270
	for <info-performer@sgi.com>; Sun, 10 May 1998 17:17:01 -0700 (PDT)
	mail_from (asano@iida.sse.co.jp)
Received: from iida.sse.co.jp ([172.25.65.200]) by sse.co.jp (8.8.8/3.4W4) with ESMTP id JAA07997 for <info-performer@sgi.com>; Mon, 11 May 1998 09:03:40 +0900 (JST)
Received: from andrew ([172.25.145.12])
	by iida.sse.co.jp (8.8.8/3.6W) with ESMTP id JAA03190
	for <info-performer@sgi.com>; Mon, 11 May 1998 09:15:20 +0900 (JST)
Message-ID: <355643AE.D4CBCFEE@iida.sse.co.jp>
Date: Mon, 11 May 1998 09:17:51 +0900
From: Tatsuya Asano <asano@iida.sse.co.jp>
X-Mailer: Mozilla 4.01 [ja] (WinNT; I)
MIME-Version: 1.0
To: "info-performer@sgi.com" <info-performer@sgi.com>
Subject: about molecular inventor
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Status: O

Hello,

I'd like to know how to read molecular inventor file on Performer.
I installed$B!!(J Molecular Inventor Execution Only Environment, 1.1,
but I couldn't.

Is there any software that I have to install?

Thank you in advance,

$B!!(J
$B!!!!!!!!!!!!!!(J Tatsuya Asano
Sumisho Electronics Co.,Ltd.
$B!!(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  Mon May 11 07:33:33 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA25386 for info-performer-dist@holodeck.engr.sgi.com; Mon, 11 May 1998 07: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 HAA25359 for <info-performer@holodeck.engr.sgi.com>; Mon, 11 May 1998 07:14: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 HAA23251715
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 11 May 1998 07:14:51 -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 HAA25260
	for <info-performer@sgi.com>; Mon, 11 May 1998 07:14:50 -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 AAA28181
          for <info-performer@sgi.com>; Mon, 11 May 1998 10:12:38 -0400
Message-ID: <355707D0.83E61E40@bah.com>
Date: Mon, 11 May 1998 10:14:41 -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: nomore"save as"
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Hello pffolks;

I'm running 15.4 and lately I've had to save all my models as v14.2
because the scenes

are dark when run in perfly.  I know I need to "setenv" to point to the
correct loader.

Could someone enlighten with the correct command line path?

I realize this is a basic call but bare with me, my sys admin. guy has
no clue......

thanks

clueless in D.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  Mon May 11 07:55:08 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA25652 for info-performer-dist@holodeck.engr.sgi.com; Mon, 11 May 1998 07:48: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 HAA25625 for <info-performer@holodeck.engr.sgi.com>; Mon, 11 May 1998 07:48: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 HAA12907261;
	Mon, 11 May 1998 07:48:00 -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 HAA05806; Mon, 11 May 1998 07:47:58 -0700 (PDT)
	mail_from (dery@discreet.com)
Received: from cuba by helios.Discreet.QC.CA
	id KAA14909; Mon, 11 May 1998 10:47:35 -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 KAA01946; Mon, 11 May 1998 10:47:54 -0400
Received: (from dery@localhost) by atlantis (950413.SGI.8.6.12/) id KAA16318; Mon, 11 May 1998 10:47:53 -0400
From: "Jean-Luc Dery" <dery@discreet.com>
Message-Id: <9805111047.ZM16296@atlantis>
Date: Mon, 11 May 1998 10:47:53 -0400
In-Reply-To: Scott Herod <herod@evt.com>
        "Deleting textures in 2.0.x" (May  8,  5:20pm)
References: <35539324.40D03077@evt.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Scott Herod <herod@evt.com>, info-performer@sgi.com
Subject: Re: Deleting textures in 2.0.x
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On May 8,  5:20pm, Scott Herod wrote:
> Subject: Deleting textures in 2.0.x
> I need to manually delete textures.  The following works (or appears
> to) in 2.2.
>
>     pfTexture *tex;
>     tex->deleteGLHandle();   // For Performer 2.2
>
> However pfObjects don't know that call in 2.0.4.  Is there something
> similar that I can do in 2.0.4?  I've got a reference here to a call
>
>     // _pfDeleteTexHandle(tex);    // For Performer 2.0.x
>
> but can't find anything even similar.

This call is hidden in the Performer 2.1.3 libraries. In order to use it, you
must define the following:

extern "C" int _pfDeleteTexHandle(pfTexture *tex);


The 2.1.3 eoe is part of the Performer 2.2 distribution and is the
compatibility libraries for 2.1. The problem is that it has some issues with
the way lighting is managed. In our case, we have had problems with getting
proper colors and materials rendered and has proven to be usable. Read the
mails exchanged on this for the last past two weeks.

Hope this enlights,

Jean-Luc

-- 
_____________________________________________________________________________

Jean-Luc Dery                         Discreet Logic
Technical Leader                      10 Duke Street
3-D Graphics Technology and           Montreal (Quebec), Canada, H3C 2L7
Realtime Systems                      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  Mon May 11 10:34:10 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA26244 for info-performer-dist@holodeck.engr.sgi.com; Mon, 11 May 1998 10:09: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 KAA26217 for <info-performer@holodeck.engr.sgi.com>; Mon, 11 May 1998 10:09:37 -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 KAA18557140
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 11 May 1998 10:09:36 -0700 (PDT)
Received: from grover.brooks.af.mil (grover.brooks.af.mil [140.140.4.221]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id KAA08642
	for <info-performer@sgi.com>; Mon, 11 May 1998 10:09:34 -0700 (PDT)
	mail_from (jcoffman@grover.brooks.af.mil)
Received: from grover.brooks.af.mil (jcoffman@hrd612.brooks.af.mil [140.140.14.212]) by grover.brooks.af.mil (8.7.5/8.7.3) with ESMTP id MAA26562 for <info-performer@sgi.com>; Mon, 11 May 1998 12:09:27 -0500
Sender: jcoffman@grover.brooks.af.mil
Message-ID: <3557309E.8C4C97ED@grover.brooks.af.mil>
Date: Mon, 11 May 1998 12:08:46 -0500
From: Jarrett Coffman <jcoffman@grover.brooks.af.mil>
Organization: AFRL/HEJT Brooks AFB
X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.29 i586)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: Texture problems
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

We have 3 Indigo2 MAX IMPACT machines, and on 2 of the 3 machines we are
having trouble displaying textures. Grayscale textures look pinkish or
distorted. We tried upgrading one of the "bad" machines from 2.0.4 to
2.2 and had the same problem.

We think that it might be either an X server or OpenGL bug. When we run
the program over the network and display it on another machine (O2) the
textures look good.

Anyone run across this before?

Thanks.

-- 
Jarrett Coffman
BTG/Delta Research Division
AFRL/HEJT Brooks AFB
jcoffman@grover.brooks.af.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  Mon May 11 11:12:43 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA26374 for info-performer-dist@holodeck.engr.sgi.com; Mon, 11 May 1998 10:54: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 KAA26344 for <info-performer@holodeck.engr.sgi.com>; Mon, 11 May 1998 10:54: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 KAA21850369
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 11 May 1998 10:54:56 -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 KAA28186
	for <info-performer@sgi.com>; Mon, 11 May 1998 10:53:25 -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 KAA32163; Mon, 11 May 1998 10:53:22 -0700 (PDT)
From: "Rob Jenkins" <robj@quid.engr.sgi.com>
Message-Id: <9805111053.ZM31857@quid.engr.sgi.com>
Date: Mon, 11 May 1998 10:53:21 -0700
In-Reply-To: Jarrett Coffman <jcoffman@grover.brooks.af.mil>
        "Texture problems" (May 11, 12:08pm)
References: <3557309E.8C4C97ED@grover.brooks.af.mil>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Jarrett Coffman <jcoffman@grover.brooks.af.mil>, info-performer@sgi.com
Subject: Re: Texture problems
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On May 11, 12:08pm, Jarrett Coffman wrote:
> Subject: Texture problems
> We have 3 Indigo2 MAX IMPACT machines, and on 2 of the 3 machines we are
> having trouble displaying textures. Grayscale textures look pinkish or
> distorted. We tried upgrading one of the "bad" machines from 2.0.4 to
> 2.2 and had the same problem.
>
> We think that it might be either an X server or OpenGL bug. When we run
> the program over the network and display it on another machine (O2) the
> textures look good.
>
> Anyone run across this before?

I have heard of exactly this when High Impact machines were upgraded to Max
Impact machines incorrectly. A Max Impact is essentially 2 High Impact pipes in
parallel  ( parallel GEs and TRAM ) so the TRAM is duplicated internally. In
short a Max Impact with 4M TRAM actually has 2 X 4TRAM inside ( more texture
throughput rather than capacity ). If a High gets upgraded to Max but only has
one set of TRAM then this effect happens.

If it's not that then you could just have a dodgy TRAM board, even though it's
2 machines with the same problem it might be the same/similar HW problem on
both, one test would be to pull swap the system disk from a good machien to a
bad machine, if the problem follows the disk ( which I doubt ) then it's SW, if
the problem stays with the HW then I suggest you log a HW support call.

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  Mon May 11 12:06:04 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA27115 for info-performer-dist@holodeck.engr.sgi.com; Mon, 11 May 1998 11:49: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 LAA27088 for <info-performer@holodeck.engr.sgi.com>; Mon, 11 May 1998 11:49: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 LAA23300827
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 11 May 1998 11:49:24 -0700 (PDT)
Received: from austin.cs.unc.edu (austin.cs.unc.edu [152.2.128.87]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id LAA20279
	for <info-performer@sgi.com>; Mon, 11 May 1998 11:47:33 -0700 (PDT)
	mail_from (zhangh@cs.unc.edu)
Received: from capefear.cs.unc.edu (capefear.cs.unc.edu [152.2.128.19])
	by austin.cs.unc.edu (8.8.8/8.8.8) with ESMTP id OAA03684;
	Mon, 11 May 1998 14:47:31 -0400 (EDT)
Received: (from zhangh@localhost)
	by capefear.cs.unc.edu (8.8.8/8.8.8) id OAA03627;
	Mon, 11 May 1998 14:47:30 -0400 (EDT)
From: Hansong Zhang <zhangh@cs.unc.edu>
Message-Id: <199805111847.OAA03627@capefear.cs.unc.edu>
Subject: Re: Texture problems
To: robj@quid.engr.sgi.com (Rob Jenkins)
Date: Mon, 11 May 1998 14:47:30 -0400 (EDT)
Cc: jcoffman@grover.brooks.af.mil, info-performer@sgi.com
In-Reply-To: <9805111053.ZM31857@quid.engr.sgi.com> from "Rob Jenkins" at May 11, 98 10:53:21 am
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Status: O

> 
> On May 11, 12:08pm, Jarrett Coffman wrote:
> > Subject: Texture problems
> > We have 3 Indigo2 MAX IMPACT machines, and on 2 of the 3 machines we are
> > having trouble displaying textures. Grayscale textures look pinkish or
> > distorted. We tried upgrading one of the "bad" machines from 2.0.4 to
> > 2.2 and had the same problem.
> >
> > We think that it might be either an X server or OpenGL bug. When we run
> > the program over the network and display it on another machine (O2) the
> > textures look good.
> >
> > Anyone run across this before?
> 
> I have heard of exactly this when High Impact machines were upgraded to Max
> Impact machines incorrectly. A Max Impact is essentially 2 High Impact pipes in
> parallel  ( parallel GEs and TRAM ) so the TRAM is duplicated internally. In
> short a Max Impact with 4M TRAM actually has 2 X 4TRAM inside ( more texture
> throughput rather than capacity ). If a High gets upgraded to Max but only has
> one set of TRAM then this effect happens.
> 
> If it's not that then you could just have a dodgy TRAM board, even though it's
> 2 machines with the same problem it might be the same/similar HW problem on
> both, one test would be to pull swap the system disk from a good machien to a
> bad machine, if the problem follows the disk ( which I doubt ) then it's SW, if
> the problem stays with the HW then I suggest you log a HW support call.
> 

Here at UNC we've been having problems with texture mapping on MaxImpacts
since day one. One of the problems is that texture can appear interleaved 
with black or gray lines. Since Max users here don't seriously use textures
the problem not got high priority and remains still there.

Recently a network guy working on a MaxImpact happened to notice that a 
board was only loosely plugged in, so he proceeded to push it home - and
therefore solved the texture problem on that machine :-) We have yet to
check whether boards in other Impacts are really in their slots.

Hansong
=======================================================================
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 May 11 12:06:04 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA27179 for info-performer-dist@holodeck.engr.sgi.com; Mon, 11 May 1998 11:58: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 LAA27152 for <info-performer@holodeck.engr.sgi.com>; Mon, 11 May 1998 11:58: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 LAA23398086
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 11 May 1998 11:58:34 -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 LAA24145
	for <info-performer@sgi.com>; Mon, 11 May 1998 11:57:28 -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 LAA34156; Mon, 11 May 1998 11:53:55 -0700 (PDT)
From: "Rob Jenkins" <robj@quid.engr.sgi.com>
Message-Id: <9805111153.ZM34097@quid.engr.sgi.com>
Date: Mon, 11 May 1998 11:53:54 -0700
In-Reply-To: Hansong Zhang <zhangh@cs.unc.edu>
        "Re: Texture problems" (May 11,  2:47pm)
References: <199805111847.OAA03627@capefear.cs.unc.edu>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Hansong Zhang <zhangh@cs.unc.edu>
Subject: Re: Texture problems
Cc: jcoffman@grover.brooks.af.mil, info-performer@sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On May 11,  2:47pm, Hansong Zhang wrote:
> Subject: Re: Texture problems
> >
> > On May 11, 12:08pm, Jarrett Coffman wrote:
> > > Subject: Texture problems
> > > We have 3 Indigo2 MAX IMPACT machines, and on 2 of the 3 machines we are
> > > having trouble displaying textures. Grayscale textures look pinkish or
> > > distorted. We tried upgrading one of the "bad" machines from 2.0.4 to
> > > 2.2 and had the same problem.
> > >
> > > We think that it might be either an X server or OpenGL bug. When we run
> > > the program over the network and display it on another machine (O2) the
> > > textures look good.
> > >
> > > Anyone run across this before?
> >
> > I have heard of exactly this when High Impact machines were upgraded to Max
> > Impact machines incorrectly. A Max Impact is essentially 2 High Impact
pipes in
> > parallel  ( parallel GEs and TRAM ) so the TRAM is duplicated internally.
In
> > short a Max Impact with 4M TRAM actually has 2 X 4TRAM inside ( more
texture
> > throughput rather than capacity ). If a High gets upgraded to Max but only
has
> > one set of TRAM then this effect happens.
> >
> > If it's not that then you could just have a dodgy TRAM board, even though
it's
> > 2 machines with the same problem it might be the same/similar HW problem on
> > both, one test would be to pull swap the system disk from a good machien to
a
> > bad machine, if the problem follows the disk ( which I doubt ) then it's
SW, if
> > the problem stays with the HW then I suggest you log a HW support call.
> >
>
> Here at UNC we've been having problems with texture mapping on MaxImpacts
> since day one. One of the problems is that texture can appear interleaved
> with black or gray lines. Since Max users here don't seriously use textures
> the problem not got high priority and remains still there.
>
> Recently a network guy working on a MaxImpact happened to notice that a
> board was only loosely plugged in, so he proceeded to push it home - and
> therefore solved the texture problem on that machine :-) We have yet to
> check whether boards in other Impacts are really in their slots.
>
> Hansong
>-- End of excerpt from Hansong Zhang

That sounds like badly seated TRAM boards, the most common cause of texture
funny business on TRAM. Do be careful about touching this stuff your self
though as it's super sensitive to static, if in doubt, have an SGI SE check the
HW out.

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  Mon May 11 12:23:56 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA27220 for info-performer-dist@holodeck.engr.sgi.com; Mon, 11 May 1998 12:06: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 MAA27193 for <info-performer@holodeck.engr.sgi.com>; Mon, 11 May 1998 12:06: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 MAA23424485
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 11 May 1998 12:06: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 MAA26719
	for <info-performer@sgi.com>; Mon, 11 May 1998 12:04: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 MAA23331098;
	Mon, 11 May 1998 12:04: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 MAA02993; Mon, 11 May 1998 12:04:09 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <35574BA9.97AF3DB2@sgi.com>
Date: Mon, 11 May 1998 12:04: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: Jarrett Coffman <jcoffman@grover.brooks.af.mil>
CC: info-performer@sgi.com
Subject: Re: Texture problems
References: <3557309E.8C4C97ED@grover.brooks.af.mil>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Jarrett Coffman wrote:
> 
> We have 3 Indigo2 MAX IMPACT machines, and on 2 of the 3 machines we are
> having trouble displaying textures. Grayscale textures look pinkish or
> distorted. We tried upgrading one of the "bad" machines from 2.0.4 to
> 2.2 and had the same problem.
> 
> We think that it might be either an X server or OpenGL bug. When we run
> the program over the network and display it on another machine (O2) the
> textures look good.
> 
> Anyone run across this before?
> 

Is your grey scale texture actually gray or is it a grey ggb?


Could this be caused by component quantization due to low number
of bits per colour component on internal format on IMPACT.

How much TRAM do you have on the IMPACT?

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 May 11 12:23:54 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA27271 for info-performer-dist@holodeck.engr.sgi.com; Mon, 11 May 1998 12:15: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 MAA27244 for <info-performer@holodeck.engr.sgi.com>; Mon, 11 May 1998 12:15:37 -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 MAA22817700
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 11 May 1998 12:15:35 -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 MAA01348
	for <info-performer@sgi.com>; Mon, 11 May 1998 12:14:18 -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 MAA21924068;
	Mon, 11 May 1998 12:14:15 -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 MAA03019; Mon, 11 May 1998 12:14:08 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <35574E00.44CE3FA8@sgi.com>
Date: Mon, 11 May 1998 12:14: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: Hansong Zhang <zhangh@cs.unc.edu>
CC: Rob Jenkins <robj@quid.engr.sgi.com>, jcoffman@grover.brooks.af.mil,
        info-performer@sgi.com
Subject: Re: Texture problems
References: <199805111847.OAA03627@capefear.cs.unc.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Hansong Zhang wrote:
> 

> Here at UNC we've been having problems with texture mapping on MaxImpacts
> since day one. One of the problems is that texture can appear interleaved
> with black or gray lines. Since Max users here don't seriously use textures
> the problem not got high priority and remains still there.
> 
> Recently a network guy working on a MaxImpact happened to notice that a
> board was only loosely plugged in, so he proceeded to push it home - and
> therefore solved the texture problem on that machine :-) We have yet to
> check whether boards in other Impacts are really in their slots.

Well that would be a start. Didn't you guys think if logging a
support call? MAY IMPACT textured fill performance is pretty handy
particularly when compared to other workstation offerings.

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 May 11 13:13:03 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA27880 for info-performer-dist@holodeck.engr.sgi.com; Mon, 11 May 1998 12:53: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 MAA27853 for <info-performer@holodeck.engr.sgi.com>; Mon, 11 May 1998 12:53: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 MAA23449174
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 11 May 1998 12:53:18 -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 MAA18687
	for <info-performer@sgi.com>; Mon, 11 May 1998 12:53: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 NAA09652 for <info-performer@sgi.com>; Mon, 11 May 1998 13:04:20 -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 TAA13266 for <@plateau.engr.multigen.com:info-performer@sgi.com>; Mon, 11 May 1998 19:54:33 GMT
Received: (from marcus@localhost) by logan.engr.multigen.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id MAA06347 for info-performer@sgi.com; Mon, 11 May 1998 12:54:32 -0700
From: "Marcus Barnes" <marcus@multigen.com>
Message-Id: <9805111254.ZM6345@logan.engr.multigen.com>
Date: Mon, 11 May 1998 12:54:32 -0700
In-Reply-To: Angus Dorbie <dorbie@sgi.com>
        "Re: Alpha and anti-aliasing..." (May  8,  7:35pm)
References: <199805082123.OAA20373@archimedes.vislab.navy.mil> 
	<9805081905.ZM20192@southpark.engr.sgi.com> 
	<3553C10B.791D4745@sgi.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: Alpha and anti-aliasing...
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On May 8,  7:35pm, Angus Dorbie wrote:
>Allan Schaffer wrote:
>> You're running into two of the places where Performer's default
>> behavior chooses 'fast' instead of 'high quality':  #1 with
>> transparency (when ms is enabled it uses subpixel alpha by default
>> instead of blending) and #2 with texture formats (textures are
>> reduced to 16 bits by default)
>
>Yes but this gives 4 bits or 8 bits of precision (depending
>on RGBA or IA components) which gives 16 or 256 shades of
>alpha, not ~4.

It could also give 1 or 2 bits of alpha ... as defined by the
GL_UNSIGNED_SHORT_5_5_5_1_EXT and GL_UNSIGNED_INT_10_10_10_2_EXT internal
(pixel) formats.

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-4103       +
=======================================================================
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 May 11 13:44:53 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA28152 for info-performer-dist@holodeck.engr.sgi.com; Mon, 11 May 1998 13:34: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 NAA28125 for <info-performer@holodeck.engr.sgi.com>; Mon, 11 May 1998 13:34: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 NAA23199221
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 11 May 1998 13:34: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 NAA08982
	for <info-performer@sgi.com>; Mon, 11 May 1998 13:34:34 -0700 (PDT)
	mail_from (cano@silicon.cl)
Mtz-Posted-Date: Mon, 11 May 1998 17:33:41 -0700
Received: from ivory.silicon.cl(200.29.40.2) by challenge via smap (3.1)
	id xma003681; Mon, 11 May 98 17:33:33 -0700
Received: from krusty (krusty [200.29.40.72]) by silicon.cl (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA23525; Mon, 11 May 1998 16:34:26 -0400
Received: (from cano@localhost) by krusty (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA28434; Mon, 11 May 1998 16:47:49 -0400
From: "Alejandro Saez" <cano@silicon.cl>
Message-Id: <9805111647.ZM28432@krusty>
Date: Mon, 11 May 1998 16:47:48 -0400
In-Reply-To: Jarrett Coffman <jcoffman@grover.brooks.af.mil>
        "Texture problems" (May 11, 12:08pm)
References: <3557309E.8C4C97ED@grover.brooks.af.mil>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Jarrett Coffman <jcoffman@grover.brooks.af.mil>
Subject: Re: Texture problems
Cc: info-performer@sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On May 11, 12:08pm, Jarrett Coffman wrote:
> Subject: Texture problems
> We have 3 Indigo2 MAX IMPACT machines, and on 2 of the 3 machines we are
> having trouble displaying textures. Grayscale textures look pinkish or
> distorted. We tried upgrading one of the "bad" machines from 2.0.4 to
> 2.2 and had the same problem.
>
> We think that it might be either an X server or OpenGL bug. When we run
> the program over the network and display it on another machine (O2) the
> textures look good.
>
> Anyone run across this before?
>
> Thanks.
>
> --
> Jarrett Coffman
> BTG/Delta Research Division
> AFRL/HEJT Brooks AFB
> jcoffman@grover.brooks.af.mil
> =======================================================================
> 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 Jarrett Coffman

This sounds like a HW problem, try the following:

	1) re-seat both the cards themselves and if you have the TRAM option
re-seat them too. Ohh, by the way, a while ago we needed a TRAM option for our
MAX IMPACT and borrowed one from someone who had a HIGH IMPACT. We had problems
similar to the ones described by you. The problem is that for MAX IMPACT you
need 2 4MB TRAM cards, one for each raster manager (third and second, or top
and last before top cards, this doesn't give you 8 MB, but faster and, I guess,
deeper 4 MB of  texture memory). By very careful while manipulating the boards
and SPECIALLY the TRAM cards, very sensitive to static.
	2) If you have the TRAM option, make sure both TRAM cards are OK, you
can do that by testing each one in a HIGH IMPACT Indigo, or try taking off the
third (top) board of the MAX IMPACT, to make it a HIGH IMPACT, and then trying
each TRAM card. If the problems persist, then you probably have a bad card.
(Again make sure it is well seated, all contacts should be deep and evenly into
the socket, the TRAM cards tend to come out at either one of the ends).
	3) To make sure it is not software, and if you have the TRAM option,
just try the borads without the TRAM cards.

	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  Mon May 11 13:44:56 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA28091 for info-performer-dist@holodeck.engr.sgi.com; Mon, 11 May 1998 13:31: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 NAA28064 for <info-performer@holodeck.engr.sgi.com>; Mon, 11 May 1998 13:31: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 NAA21168944
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 11 May 1998 13:31:20 -0700 (PDT)
Received: from acusoft.com (acusoft.acusoft.com [205.187.235.130]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id NAA07649
	for <info-performer@sgi.com>; Mon, 11 May 1998 13:31:18 -0700 (PDT)
	mail_from (miller@acusoft.com)
Received: from distest by acusoft.com (5.x/SMI-SVR4)
	id AA14111; Mon, 11 May 1998 16:31:17 -0400
Received: by distest (950413.SGI.8.6.12) id QAA26742; Mon, 11 May 1998 16:31:16 -0400
Date: Mon, 11 May 1998 16:31:16 -0400 (EDT)
From: "Thomas M. Miller" <miller@acusoft.com>
X-Sender: miller@distest
To: info-performer@sgi.com
Subject: inf/60.0
Message-Id: <Pine.SGI.3.91.980511162958.25788E-100000@distest>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O


I'm getting inf/60.0 in my frame stats display. What does this mean?
How can I fix this problem?

--TMIV

=======================================================================
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 May 11 14:20:57 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA28724 for info-performer-dist@holodeck.engr.sgi.com; Mon, 11 May 1998 14:08: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 OAA28688 for <info-performer@holodeck.engr.sgi.com>; Mon, 11 May 1998 14:08: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 OAA23207561
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 11 May 1998 14:07:59 -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 OAA23440
	for <info-performer@sgi.com>; Mon, 11 May 1998 14:07:56 -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 AA04713; Mon, 11 May 98 14:07:57 PDT
Sender: howard@cs.nps.navy.mil
Message-Id: <355768AC.9DB740E3@cs.nps.navy.mil>
Date: Mon, 11 May 1998 14:07:56 -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: info-performer@sgi.engr.sgi.com
Subject: Re: inf/60.0
References: <Pine.SGI.3.91.980511162958.25788E-100000@distest>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Thomas M. Miller wrote:
> 
> I'm getting inf/60.0 in my frame stats display. What does this mean?
> How can I fix this problem?
> 

I've seen problems with pfGetTime, and other timings within Performer
when VME hardware is used. Some sort of weird-o interupt problem. Do
you have a scram-net board, or any other non-standard hardware?

h.

--
Howard Abrams
NPSnet Research Group
abramsh@acm.org
=======================================================================
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 May 11 15:58:12 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA29228 for info-performer-dist@holodeck.engr.sgi.com; Mon, 11 May 1998 15:47: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 PAA29201 for <info-performer@holodeck.engr.sgi.com>; Mon, 11 May 1998 15:47: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 PAA5898343
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 11 May 1998 15:47:16 -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 PAA06766
	for <info-performer@sgi.com>; Mon, 11 May 1998 15:47:14 -0700 (PDT)
	mail_from (WRVO@chevron.com)
Received: (from uucp@localhost)
	by portalcp.chevron.com (8.8.8/8.8.8) id PAA29436
	for <info-performer@sgi.com>; Mon, 11 May 1998 15:47:13 -0700 (PDT)
Received: from unknown(146.27.64.35) by portalcp.chevron.com via smap (4.0a)
	id xmaf28983; Mon, 11 May 98 15:46:50 -0700
Received: by chvpk-msx04-b.sr.chevron.com with Internet Mail Service (5.0.1460.8)
	id <KX6K7W5G>; Mon, 11 May 1998 15:45:25 -0700
Message-ID: <39EA81D694E0D111AC1A00805F6FBF0B0D8AF9@hou281-msx2.chevron.com>
From: "Volz, Bill (wrvo)" <WRVO@chevron.com>
To: "'info-performer@sgi.com'" <info-performer@sgi.com>
Subject: problems with isect
Date: Mon, 11 May 1998 15:45:24 -0700
X-Mailer: Internet Mail Service (5.0.1460.8)
Status: O

I am having trouble using isect. The problem is that it does not return the
correct pick. I have set up the eye direction and other things in the
pfSegSet and added a discFunc callback to see what is happening. The object
that I'm isect'ing with is a simple cube and all quads of the cube have back
face culling turned off. The six quads are the only thing in the model that
has a non-zero isect mask (I've checked this by descending the scene graph
and printing the mask for each node). I've also checked that the all the
nodes have the isect cache updated and the bounding boxes are correct. With
this configuration (back face turned off and a simple cube), then the
discFunc should find two isect's and take the one closest to me. But what
I'm finding is that I frequently get is only one isect, not two. And it is
usually the one in the back of the model. If I turn back face culling on,
then when I was getting one hit, I get none.

I am at a loss to explain this behavior. Does anyone have any insight they
could provide as to why this is happening or areas to look into?

All help would be greatly appreciated.

Bill Volz - Senior Research Geophysicist
Chevron Petroleum Technology
Voice: (281)-596-2059 Fax: (281)-493-7088

=======================================================================
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 May 11 22:36:11 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id WAA09885 for info-performer-dist@holodeck.engr.sgi.com; Mon, 11 May 1998 22: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 WAA09858 for <info-performer@holodeck.engr.sgi.com>; Mon, 11 May 1998 22:12: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 WAA23334186
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 11 May 1998 22:12:27 -0700 (PDT)
Received: from southpark.engr.sgi.com ([150.166.37.36]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id WAA05199
	for <info-performer@sgi.com>; Mon, 11 May 1998 22:12:26 -0700 (PDT)
	mail_from (allan@southpark.engr.sgi.com)
Received: (from allan@localhost) by southpark.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) id WAA38187 for info-performer@sgi.com; Mon, 11 May 1998 22:12:26 -0700 (PDT)
Date: Mon, 11 May 1998 22:12:26 -0700 (PDT)
From: allan@southpark.engr.sgi.com (Allan Schaffer)
Message-Id: <9805112212.ZM38130@southpark.engr.sgi.com>
In-Reply-To: amit@discreet.com (Amit Parghi)
        "Re: Performer 2.2 "compat" libraries ineffective?" (May  7, 10:21am)
References: <199805011614.LAA05725@impact13.ncsa.uiuc.edu> 
	<9805041332.ZM9033@logan.engr.multigen.com> 
	<9805071021.ZM3369@burkina>
X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail)
To: info-performer@sgi.com
Subject: Re: Performer 2.2 "compat" libraries ineffective?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

Hi folks - we've been digging into this problem with the "compat"
subsystems.  The RLD problem with the loader DSO's has been found &
fixed and I'm now looking into what's going on with the lighting &
colors.

If you're being effected by these problems and wouldn't mind being a
guinea pig for some tests please drop me an email.  Once it's all
fixed up we'll make the changes generally available, either as a
patch or something on the FTP site.

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  Tue May 12 00:30:44 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id AAA10163 for info-performer-dist@holodeck.engr.sgi.com; Tue, 12 May 1998 00:13: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 AAA10136 for <info-performer@holodeck.engr.sgi.com>; Tue, 12 May 1998 00:13: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 AAA23539021
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 12 May 1998 00:13:15 -0700 (PDT)
Received: from hni.uni-paderborn.de (hni-ff.uni-paderborn.de [131.234.22.55]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id AAA03216
	for <info-performer@sgi.com>; Tue, 12 May 1998 00:12:09 -0700 (PDT)
	mail_from (brandt@hni.uni-paderborn.de)
Received: from hni.uni-paderborn.de (isis [131.234.176.3]) by hni.uni-paderborn.de (8.8.4/hni-mailhub) with ESMTP id JAA28387; Tue, 12 May 1998 09:08:30 +0200 (MET DST)
Message-ID: <3557F537.7F804876@hni.uni-paderborn.de>
Date: Tue, 12 May 1998 09:07:35 +0200
From: Christoph Brandt <brandt@hni.uni-paderborn.de>
Organization: Heinz Nixdorf Institut
X-Mailer: Mozilla 4.03 [de] (WinNT; I)
MIME-Version: 1.0
To: Jarrett Coffman <jcoffman@grover.brooks.af.mil>
CC: info-performer@sgi.com
Subject: Re: Texture problems
References: <3557309E.8C4C97ED@grover.brooks.af.mil> <9805111053.ZM31857@quid.engr.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

> On May 11, 12:08pm, Jarrett Coffman wrote:
> > Subject: Texture problems
> > We have 3 Indigo2 MAX IMPACT machines, and on 2 of the 3 machines we are
> > having trouble displaying textures. Grayscale textures look pinkish or
> > distorted. We tried upgrading one of the "bad" machines from 2.0.4 to
> > 2.2 and had the same problem.
> >
> > We think that it might be either an X server or OpenGL bug. When we run
> > the program over the network and display it on another machine (O2) the
> > textures look good.
> >
> > Anyone run across this before?
> 
> I have heard of exactly this when High Impact machines were upgraded to Max
> Impact machines incorrectly. A Max Impact is essentially 2 High Impact pipes in
> parallel  ( parallel GEs and TRAM ) so the TRAM is duplicated internally. In
> short a Max Impact with 4M TRAM actually has 2 X 4TRAM inside ( more texture
> throughput rather than capacity ). If a High gets upgraded to Max but only has
> one set of TRAM then this effect happens.
> 
> If it's not that then you could just have a dodgy TRAM board, even though it's
> 2 machines with the same problem it might be the same/similar HW problem on
> both, one test would be to pull swap the system disk from a good machien to a
> bad machine, if the problem follows the disk ( which I doubt ) then it's SW, if
> the problem stays with the HW then I suggest you log a HW support call.
> 
> Cheers
> Rob

We had the same problem on an Octane MXI system. After exchanging the
TRAM the effect was gone.

Christoph
--
Christoph Brandt                Tel. ++49 +5251 60-6233
Virtual Reality Group           Fax. ++49 +5251 60-6268
Rechnerintegrierte Produktion   http://wwwhni.uni-paderborn.de/rip
Heinz Nixdorf Institut          Fuerstenallee 11 
Universitaet GH Paderborn       D-33102 Paderborn
=======================================================================
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 May 12 01:57:55 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id BAA10446 for info-performer-dist@holodeck.engr.sgi.com; Tue, 12 May 1998 01:45: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 BAA10419 for <info-performer@holodeck.engr.sgi.com>; Tue, 12 May 1998 01:45: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 BAA22987841
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 12 May 1998 01:45:53 -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 BAA22430
	for <info-performer@sgi.com>; Tue, 12 May 1998 01:45:43 -0700 (PDT)
	mail_from (liuxy@ihpc.nus.edu.sg)
Received: (from smap@localhost)
          by aba.ihpc.nus.edu.sg (8.8.5/8.8.4)
	  id QAA20121 for <info-performer@sgi.com>; Tue, 12 May 1998 16:45:38 +0800 (SGT)
Received: from liuxy.nsrc.nus.sg(137.132.15.179) by aba.nsrc.nus.sg via smap (V1.3)
	id sma020119; Tue May 12 16:45:32 1998
Message-ID: <35580C5B.271E@ihpc.nus.edu.sg>
Date: Tue, 12 May 1998 16:46:19 +0800
From: Liu Xiaoyan <liuxy@ihpc.nus.edu.sg>
Organization: Institute of High Performance Computing
X-Mailer: Mozilla 3.0 (Win95; I)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: any support for TKO?
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 7bit
Status: O

( Sorry, this may not be Performer relative.)

Can TKO be implemented on Onyx2 with 2 IR pipes?

The Onyx2 is used to drive the CAVE virtual reality system. Recently 
we buy another monitor from SGI with the hope of supporting 2 users 
at the same time when the system is not in CAVE display mode
(i.e two channels from each pipe). 

Unluckily, later we were told by SGI local support that TKO cannot 
be done on this Onyx2. No detailed reasons. 

Is there any suggestions on what we can do? Like hardware and 
software to purchase. The following is the only info from SGI 
website, but doesn't help too much.

> The TKO requires a Rack Onyx workstation with
>two or three RealityEngine2 subsystems, one POWERChannel-2 I/O >subsystem per user, additional monitors, and a TKO upgrade kit which
>includes additional keyboards, 75 foot monitor and keyboard cable >extensions, I/O panel circuitry and multiuser software. 

Thanks for any advice.

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  Tue May 12 01:57:55 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id BAA10409 for info-performer-dist@holodeck.engr.sgi.com; Tue, 12 May 1998 01:39: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 BAA10382 for <info-performer@holodeck.engr.sgi.com>; Tue, 12 May 1998 01:39: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 BAA23637962
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 12 May 1998 01:39:03 -0700 (PDT)
Received: from earth.inet.nk-exa.co.jp (earth.inet.nk-exa.co.jp [202.32.43.99]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id BAA21219
	for <info-performer@sgi.com>; Tue, 12 May 1998 01:38:58 -0700 (PDT)
	mail_from (wryperf@such.dst.nk-exa.co.jp)
Received: from such.dst.nk-exa.co.jp (such.dst.nk-exa.co.jp [160.14.100.101])
	by earth.inet.nk-exa.co.jp (8.8.8+2.7Wbeta7/3.6W-03/09/98) with SMTP id RAA05632
	for <info-performer@sgi.com>; Tue, 12 May 1998 17:38:55 +0900 (JST)
Received: (from wryperf@localhost) by such.dst.nk-exa.co.jp (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA01390; Tue, 12 May 1998 17:33:44 +0900
Message-Id: <199805120833.RAA01390@such.dst.nk-exa.co.jp>
To: info-performer@sgi.com
Subject: SYSLOG-Warning
Date: Tue, 12 May 1998 17:33:44 +0900
From: Masahiko Yamanaka <wryperf@such.dst.nk-exa.co.jp>
Status: O

Hello all!

Though this might be a simple H/W problem, I believe someone in this ML
know about this...

One of my customers has Onyx2/iR and a Performer-based application.

As running the app., sometimes the window disappears and SYSLOG says,

     WARNING:IR0:Pipe hung: on TBUS or ARM activity
     WARNING:IR0:Timeout waiting for fifo to drain ( level == 0x70a)

What does this mean, what's wrong?
Or should I explain more details? (Sorry, I have only above right now...)

Any help will be greatly appreciated!

Thank you,
--
M.Y.
=======================================================================
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 May 12 02:47:45 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id CAA10821 for info-performer-dist@holodeck.engr.sgi.com; Tue, 12 May 1998 02:37: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 CAA10794 for <info-performer@holodeck.engr.sgi.com>; Tue, 12 May 1998 02:37: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 CAA23718533
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 12 May 1998 02:37:04 -0700 (PDT)
Received: from bifrost.digi.lego.com (balder.digi.lego.com [194.239.78.1]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id CAA02394
	for <info-performer@sgi.com>; Tue, 12 May 1998 02:37:00 -0700 (PDT)
	mail_from (svend@digi.lego.com)
Received: (from gproxy@localhost) by bifrost.digi.lego.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA28515; Tue, 12 May 1998 11:37:22 +0200
Received: from puck.digi.lego.com(171.20.167.61) by bifrost via smap (3.2)
	id xma028508; Tue, 12 May 98 11:37:10 +0200
Received: from digi.lego.com (localhost [127.0.0.1]) by puck.digi.lego.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA08059; Tue, 12 May 1998 11:37:08 +0200
Sender: svend@digi.lego.com
Message-ID: <35581844.A16DA0E@digi.lego.com>
Date: Tue, 12 May 1998 11:37:08 +0200
From: Svend Tang-Petersen <svend@digi.lego.com>
Organization: LEGO
X-Mailer: Mozilla 4.04 [en] (X11; I; IRIX 6.3 IP32)
MIME-Version: 1.0
To: Liu Xiaoyan <liuxy@ihpc.nus.edu.sg>
CC: info-performer@sgi.com
Subject: Re: any support for TKO?
References: <35580C5B.271E@ihpc.nus.edu.sg>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

On Onyx2:

All you should need to do is to buy an extra monitor, mouse and
keyboard. The system already has
the connections for the second keyboard/mouse. You then hook up the 2'nd
monitor to the extra pipe
and change the default behavoiur of X on the system to run two
X-servers/login sessions
( one on pipe-0 the other on pipe-1).

I was playing briefly with this on our system, and had it working. It's
just a while ago so I've forgotten
the details.

--

 Svend Tang-Petersen, MSc

 LEGO
 Kloevermarken 120
 7190 Billund
 Denmark

 e-mail: svend@digi.lego.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 May 12 02:47:45 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id CAA10850 for info-performer-dist@holodeck.engr.sgi.com; Tue, 12 May 1998 02:38: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 CAA10823 for <info-performer@holodeck.engr.sgi.com>; Tue, 12 May 1998 02:38: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 CAA22714249
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 12 May 1998 02:38:56 -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 CAA02661
	for <info-performer@sgi.com>; Tue, 12 May 1998 02:38:53 -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)
	 id RAA13506; Tue, 12 May 1998 17:37:38 +0800
Received: (from tzelin@localhost) by nuno.singapore.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id CAA27547; Tue, 12 May 1998 02:25:05 -0700
From: "Ong Tze Lin" <tzelin@nuno.singapore.sgi.com>
Message-Id: <9805120225.ZM27545@nuno.singapore.sgi.com>
Date: Tue, 12 May 1998 02:25:05 -0700
In-Reply-To: Liu Xiaoyan <liuxy@ihpc.nus.edu.sg>
        "any support for TKO?" (May 12,  4:46pm)
References: <35580C5B.271E@ihpc.nus.edu.sg>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Liu Xiaoyan <liuxy@ihpc.nus.edu.sg>, info-performer@sgi.com
Subject: Re: any support for TKO?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

Hi Xiaoyan,

I believe TKO was specifically an Onyx(1) product.  With the Onyx2 with
multiple pipes, you can support more than one simultaneous user by
reconfiguring the X server.  The hardware already supports this since each IO6
panel comes with two sets of mouse/keyboard ports.

You'll need a number of graphics pipes equal to the number of simultaneous
users you wish to support.  Therefore to support two users you will need two
pipes; each keyboard/mouse pair will use one pipe.  I think there was a slew of
email on this list recently related to this topic.

I'll give you a call personally tomorrow.

Cheers,
tzelin

On May 12,  4:46pm, Liu Xiaoyan wrote:
> Subject: any support for TKO?
> ( Sorry, this may not be Performer relative.)
>
> Can TKO be implemented on Onyx2 with 2 IR pipes?
>
> The Onyx2 is used to drive the CAVE virtual reality system. Recently
> we buy another monitor from SGI with the hope of supporting 2 users
> at the same time when the system is not in CAVE display mode
> (i.e two channels from each pipe).
>
> Unluckily, later we were told by SGI local support that TKO cannot
> be done on this Onyx2. No detailed reasons.
>
> Is there any suggestions on what we can do? Like hardware and
> software to purchase. The following is the only info from SGI
> website, but doesn't help too much.
>
> > The TKO requires a Rack Onyx workstation with
> >two or three RealityEngine2 subsystems, one POWERChannel-2 I/O >subsystem
per user, additional monitors, and a TKO upgrade kit which
> >includes additional keyboards, 75 foot monitor and keyboard cable
>extensions, I/O panel circuitry and multiuser software.
>
> Thanks for any advice.
>
> 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
>-- End of excerpt from Liu Xiaoyan



-- 
Ong Tze Lin 				Technical Consultant	
Silicon Graphics ASEAN HQ		High-Performance Computer Graphics
89 Science Park Dr. #03-03 to 06 	
The Rutherford, Singapore 118261	Tel: (065)777 3088  Fax: (065)779 3650      
   
=======================================================================
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 May 12 03:06:47 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id CAA10910 for info-performer-dist@holodeck.engr.sgi.com; Tue, 12 May 1998 02:51: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 CAA10882 for <info-performer@holodeck.engr.sgi.com>; Tue, 12 May 1998 02:51: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 CAA23640913
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 12 May 1998 02:51:05 -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 CAA04754
	for <info-performer@sgi.com>; Tue, 12 May 1998 02:51:03 -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)
	 id RAA13541; Tue, 12 May 1998 17:49:50 +0800
Received: (from tzelin@localhost) by nuno.singapore.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id CAA27567; Tue, 12 May 1998 02:38:10 -0700
From: "Ong Tze Lin" <tzelin@nuno.singapore.sgi.com>
Message-Id: <9805120238.ZM27565@nuno.singapore.sgi.com>
Date: Tue, 12 May 1998 02:38:10 -0700
In-Reply-To: Masahiko Yamanaka <wryperf@such.dst.nk-exa.co.jp>
        "SYSLOG-Warning" (May 12,  5:33pm)
References: <199805120833.RAA01390@such.dst.nk-exa.co.jp>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: info-performer@sgi.com, Masahiko Yamanaka <wryperf@such.dst.nk-exa.co.jp>
Subject: Re: SYSLOG-Warning
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

Hi

Have you tried running irsaudit to pinpoint the problem?  I have come across
this kind of error message several times and more often than not its due to a
bad (or badly-seated) RM board.

Run irsaudit as root off a laptop or dumb terminal, but not on the graphics
console:

First, stop graphics with /usr/gfx/stopgfx.

Run /usr/diags/IR/bin/irsaudit and sit back while it churns away.  It will take
some time to complete and return, but it will display its test results along
the way- you'll know if you have bad parts.

Restart graphics with /usr/gfx/startgfx.

Hope this helps.

Tzelin

On May 12,  5:33pm, Masahiko Yamanaka wrote:
> Subject: SYSLOG-Warning
> Hello all!
>
> Though this might be a simple H/W problem, I believe someone in this ML
> know about this...
>
> One of my customers has Onyx2/iR and a Performer-based application.
>
> As running the app., sometimes the window disappears and SYSLOG says,
>
>      WARNING:IR0:Pipe hung: on TBUS or ARM activity
>      WARNING:IR0:Timeout waiting for fifo to drain ( level == 0x70a)
>
> What does this mean, what's wrong?
> Or should I explain more details? (Sorry, I have only above right now...)
>
> Any help will be greatly appreciated!
>
> Thank you,
> --
> M.Y.
> =======================================================================
> 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 Masahiko Yamanaka



-- 
Ong Tze Lin 				Technical Consultant	
Silicon Graphics ASEAN HQ		High-Performance Computer Graphics
89 Science Park Dr. #03-03 to 06 	
The Rutherford, Singapore 118261	Tel: (065)777 3088  Fax: (065)779 3650      
   
=======================================================================
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 May 12 09:51:38 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA11891 for info-performer-dist@holodeck.engr.sgi.com; Tue, 12 May 1998 09:41: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 JAA11864 for <info-performer@holodeck.engr.sgi.com>; Tue, 12 May 1998 09:41: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 JAA24051374
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 12 May 1998 09:41:39 -0700 (PDT)
Received: from web4.rocketmail.com (web4.rocketmail.com [205.180.57.78]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id JAA06125
	for <info-performer@sgi.com>; Tue, 12 May 1998 09:41:38 -0700 (PDT)
	mail_from (joaquim@rocketmail.com)
Message-ID: <19980512163851.21363.rocketmail@web4.rocketmail.com>
Received: from [194.65.241.1] by web4; Tue, 12 May 1998 09:38:51 PDT
Date: Tue, 12 May 1998 09:38:51 -0700 (PDT)
From: Joaquim Muchaxo <joaquim@rocketmail.com>
Reply-To: joaquim@imersiva.ch
Subject: Fwd: unanswered :Crashes applying ClipTex. to gsets or GFO bug?
To: info-performer@sgi.com, lmiranda@buitre.madrid.sgi.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="-2139045425-126398554-894991131=:9921"
Status: O

---2139045425-126398554-894991131=:9921
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

No one answered my previous question.
So I am sending you more information about
the problem and the source code in attachment.

 I have installed patch 2922 and the aplication
crashes less times and without halt the machine

However, I am still confused, am I doing something wrong
or does the Onyx2 need aditional patches ?

I am sure this section of the code I am sending
as attachment is related to the problem since without
performing that code it never crashed.

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

---2139045425-126398554-894991131=:9921
Content-Type: message/rfc822

Return-Path: <guest@holodeck.engr.sgi.com>
Received: from deliverator.sgi.com (204.94.214.10)
  by mta1.rocketmail.com with SMTP; 7 May 1998 02:37:17 -0700
Received: from holodeck.engr.sgi.com (holodeck.engr.sgi.com [150.166.37.78]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id CAA03314; Thu, 7 May 1998 02:40:28 -0700 (PDT)
	mail_from (guest@holodeck.engr.sgi.com)
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id CAA04509 for info-performer-dist@holodeck.engr.sgi.com; Thu, 7 May 1998 02:16:45 -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 CAA04482 for <info-performer@holodeck.engr.sgi.com>; Thu, 7 May 1998 02:16: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 CAA21541044
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 7 May 1998 02:16:41 -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 CAA23954
	for <info-performer@sgi.com>; Thu, 7 May 1998 02:16:40 -0700 (PDT)
	mail_from (joaquim@rocketmail.com)
Message-ID: <19980507091309.6459.rocketmail@attach1.rocketmail.com>
Received: from [194.65.248.232] by attach1; Thu, 07 May 1998 02:13:09 PDT
Date: Thu, 7 May 1998 02:13:09 -0700 (PDT)
From: Joaquim Muchaxo <joaquim@rocketmail.com>
Reply-To: joaquim@imersiva.ch
Subject: X Crashes applying ClipTex. to gsets in Scene-G.
To: info-performer@sgi.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 3144

Hi,
I have a inventor file that I converted to pfb with
pfconv. 
The file has gsets that may be used by multiple
LODs (ie one gset may be used by two LOD children)

I apply a cliptexture to all gsets in the scene-graph
successfully. However sometimes the aplication crashes
the X window manager.

I have removed the traversal that aplies the gstate
to every gset and it does not crash.
I have attached the source code. Would you help
me to debug it ?

Note: Neither of the versions in geoset_apply_geostate
(commented and uncommented) are crash free.

Best Regards,
Joaquim

---------------------------------------
void geoset_apply_geostate( pfGeoSet *GeoSet, pfGeoState *
gstate) { 
/*
  pfGeoState *gs = pfGetGSetGState(GeoSet);
  
  if( !gs)
    printf("no gstate"); 
    
  if( pfGetGStateAttr(gs, PFSTATE_TEXTURE) == ct ) {
    printf("gstate already has a cliptexture"); 
    return;
  }  
      
  pfGStateMode(gs, PFSTATE_ENTEXTURE, PF_ON);
  pfGStateAttr(gs, PFSTATE_TEXTURE, ct);
  pfGStateMode(gs, PFSTATE_ENLIGHTING, PF_ON); 
*/  

  pfGSetGState( GeoSet, NULL);  /* to remove current
gstate*/
  pfGSetGState( GeoSet, (pfGeoState *)gstate );  
}


void traverse_nodes( pfNode *node, process_node_fn todo,  
      void *data) {
  int	i, n;

  if (node == NULL || todo==NULL) {
    printf("traverse_nodes: node or 'to do' function is   
NULL");
    return;
  }
 
  if( !todo( node, data) )
    return; /* prune traversal */        

  if (pfIsOfType(node, pfGetGroupClassType())) {
  
    n = pfGetNumChildren((pfGroup *)node);					
    for (i = 0; i < n; i++)
      traverse_nodes( pfGetChild( (pfGroup *)node, i),
todo,         data );
  }   
    /* other type, such as light, prune traversal */	  
}



main () {


    ct = pfdLoadClipTexture(ClipTexFileName);
    Shared->mpcliptex = pfNewMPClipTexture();

    pfMPClipTextureClipTexture(Shared->mpcliptex, ct);
    (void)pfuAddMPClipTextureToPipes(Shared->mpcliptex,
pfGetPipe(0), NULL);

......
/* set up geo state */
    GeoState = pfNewGState(arena);
    pfGStateMode(GeoState, PFSTATE_ENTEXTURE, PF_ON);
    pfGStateAttr(GeoState, PFSTATE_TEXTURE, ct); 
    pfGStateMode(GeoState, PFSTATE_ENLIGHTING, PF_ON);

.......

if( TerrainFileName)
      Shared->terrain= pfdLoadFile( TerrainFileName ); 
      
  if( Shared->terrain) {          
    pfAddChild(root, Shared->terrain);      
    traverse_nodes( Shared->terrain, geode_apply_geostate,
        GeoState);  
  }  
......
}



===
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





_________________________________________________________
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

---2139045425-126398554-894991131=:9921--
=======================================================================
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 May 12 09:51:38 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA11862 for info-performer-dist@holodeck.engr.sgi.com; Tue, 12 May 1998 09:40: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 JAA11835 for <info-performer@holodeck.engr.sgi.com>; Tue, 12 May 1998 09:40: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 JAA23898050
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 12 May 1998 09:40:24 -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 JAA05394
	for <info-performer@sgi.com>; Tue, 12 May 1998 09:40:22 -0700 (PDT)
	mail_from (klinge@reality.psych.umn.edu)
Received: from reality.psych.umn.edu by mhub3.tc.umn.edu; Tue, 12 May 98 11:40:11 -0500
From: James Klinge <klinge@reality.psych.umn.edu>
Message-Id: <199805121615.LAA08308@reality.psych.umn.edu>
Received: by reality.psych.umn.edu; Tue, 12 May 1998 11:15:12 -0500
Subject: pfMemory trouble.
To: info-performer@sgi.com
Date: Tue, 12 May 1998 11:15:12 -0500 (CDT)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Status: O

On our Onyx with 6.2 and Performer 2.0.4, I get this error repeated
several hundred times when loading certain files:

=> note  pfMemory::unref() Attempt to unreference memory with 0 reference count. ( Error 0 )

The same models do not produce this error when loaded on our Indigo2
with 6.2 and performer 2.2.  

Any help is appreciated,
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 May 12 10:42:44 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA12223 for info-performer-dist@holodeck.engr.sgi.com; Tue, 12 May 1998 10: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 KAA12196 for <info-performer@holodeck.engr.sgi.com>; Tue, 12 May 1998 10:25: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 KAA23880506
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 12 May 1998 10:25:34 -0700 (PDT)
Received: from sixty.engr.sgi.com ([198.29.106.150]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id KAA26583
	for <info-performer@sgi.com>; Tue, 12 May 1998 10:25:33 -0700 (PDT)
	mail_from (javier@sixty.engr.sgi.com)
Received: (from javier@localhost) by sixty.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA12826; Tue, 12 May 1998 10:25:16 -0700
Date: Tue, 12 May 1998 10:25:16 -0700
From: javier@sixty.engr.sgi.com (Javier Castellar)
Message-Id: <9805121025.ZM12824@sixty.engr.sgi.com>
In-Reply-To: Liu Xiaoyan <liuxy@ihpc.nus.edu.sg>
        "any support for TKO?" (May 12,  4:46pm)
References: <35580C5B.271E@ihpc.nus.edu.sg>
X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail)
To: Liu Xiaoyan <liuxy@ihpc.nus.edu.sg>, info-performer@sgi.com
Subject: Re: any support for TKO?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On May 12,  4:46pm, Liu Xiaoyan wrote:
> Subject: any support for TKO?
> ( Sorry, this may not be Performer relative.)
>
> Can TKO be implemented on Onyx2 with 2 IR pipes?

Yes we do. Even in the mimimun default multipipe configuration for Onyx2, as
soon as you have more of one pipe we do support as many keyboards/mice as
pipes, with an upper limit of two keyboards/mice per CPU module (CPU card
cage).

You are required to change a couple of Xserver config files and create a couple
of devices, but it is a step by step procedure.

We do have customers with up to 8 keyboard/mice with 8 pipes and four CPU
modules.


>
> The Onyx2 is used to drive the CAVE virtual reality system. Recently
> we buy another monitor from SGI with the hope of supporting 2 users
> at the same time when the system is not in CAVE display mode
> (i.e two channels from each pipe).
>
> Unluckily, later we were told by SGI local support that TKO cannot
> be done on this Onyx2. No detailed reasons.

I am very surprised, in any case please ask for the reasons.
If you have an Onyx2 with two pipes, you MUST be able to do it.

>
> Is there any suggestions on what we can do? Like hardware and
> software to purchase. The following is the only info from SGI
> website, but doesn't help too much.

For two pipes on Onyx2 you do not need ANY additional hardware, besides the
extra monitor, keyboard and mouse.

>
> > The TKO requires a Rack Onyx workstation with
> >two or three RealityEngine2 subsystems, one POWERChannel-2 I/O >subsystem
per user, additional monitors, and a TKO upgrade kit which
> >includes additional keyboards, 75 foot monitor and keyboard cable
>extensions, I/O panel circuitry and multiuser software.
>
> Thanks for any advice.
>
> 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
>-- End of excerpt from Liu Xiaoyan



-- 
*****************************************************************
* Javier Castellar Arribas          * Email:     javier@sgi.com *                 
*                                   * Vmail:           933-1589 *            
* Member of Technical Staff         * Phone:       650-933-1589 *
* Applied Research & Development    * Fax:         415-964-8671 *     
* Advanced Graphics Division        * MailStop:          8L-525 *
***************************************************************** 
* Silicon Graphics Inc.                                         *
* 2011 N. Shoreline Boulevard,                                  *                        
* Mountain View, California 94043-1386, USA                     *
*****************************************************************
"Violence is the last refuge of the incompetent"
						Hardin Seldon
=======================================================================
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 May 12 11:27:50 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA12471 for info-performer-dist@holodeck.engr.sgi.com; Tue, 12 May 1998 11:08: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 LAA12444 for <info-performer@holodeck.engr.sgi.com>; Tue, 12 May 1998 11:08: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 LAA23780007
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 12 May 1998 11:08:09 -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 LAA17388
	for <info-performer@sgi.com>; Tue, 12 May 1998 11:08:08 -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 LAA25298; Tue, 12 May 1998 11:08:03 -0700
Date: Tue, 12 May 1998 11:08:03 -0700
From: src@rose.engr.sgi.com (Sharon Clay)
Message-Id: <9805121108.ZM25296@rose.engr.sgi.com>
In-Reply-To: Steve Baker <sbaker@link.com>
        "Finding addresses." (May  8, 10:41am)
References: <Pine.SGI.3.96.980508102239.11922A-100000@sutcliffe.bgm.link.com>
X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail)
To: Steve Baker <sbaker@link.com>,
        Info-Performer Mailing List <info-performer@sgi.com>
Subject: Re: Finding addresses.
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

+>---- On May 8, 10:41am, Steve Baker wrote:
> Subject: Finding addresses.
->From guest@holodeck  Fri May  8 08:54:28 1998
->Date: Fri, 8 May 1998 10:41:25 -0500 (CDT)
->
->If I load an object into Performer in the DBASE task,
->and then do a pfMergeBuffer to incorporate it into
->the main scene graph, how do I find the address of
->that same object as it appears in (say) APP ?

You can just remember the address of your special node in shared memory.

>From the pfBuffer man page:

    In other words, the merged pfBuffer has been "reset" and its objects now
    "exist" only in the APP pfBuffer. The addresses of libpf objects are not
    changed by pfMergeBuffer.

->
->In the past, I connected user data to the object
->and used the pfCopyFunc callback to find the new
->copy of the object.
->
->I now realise that this should never have worked (although
->it did work - right up to the very last beta prior to
->Perf 2.2 MR). Now it fails miserably - presumably
->because the pfCopyFunc callback is also copying the
->data into CULL/ISECT/whatever - and I can't tell
->which address is the right one for APP.

The App address will be the address from the dbase process.


You also mention later that you are using AddChild and Clone before the
Merge but I don't offhand see how that changes anything - maybe I need
more info?

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 May 12 12:00:37 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA12688 for info-performer-dist@holodeck.engr.sgi.com; Tue, 12 May 1998 11:48: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 LAA12661 for <info-performer@holodeck.engr.sgi.com>; Tue, 12 May 1998 11:48: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 LAA23864703
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 12 May 1998 11:48:34 -0700 (PDT)
Received: from acusoft.com (acusoft.acusoft.com [205.187.235.130]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id LAA05841
	for <info-performer@sgi.com>; Tue, 12 May 1998 11:48:31 -0700 (PDT)
	mail_from (miller@acusoft.com)
Received: from distest by acusoft.com (5.x/SMI-SVR4)
	id AA17830; Tue, 12 May 1998 14:48:28 -0400
Received: by distest (950413.SGI.8.6.12) id OAA13553; Tue, 12 May 1998 14:48:28 -0400
Date: Tue, 12 May 1998 14:48:26 -0400 (EDT)
From: "Thomas M. Miller" <miller@acusoft.com>
X-Sender: miller@distest
To: info-performer@sgi.com
Subject: inf/60.0
Message-Id: <Pine.SGI.3.91.980512143842.12972A-100000@distest>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O


I found a correlation between the inf/60.0 and certain video modes.

My operational video mode is a 1024x768_180 stereo field sequential mode.
If I change this mode to a 60Hz mode my frame stats go back to reading
60/60. Does my 180Hz video mode have adverse effects on the VClock and
pfClock?  Could this be causing timing problems other than an erroneous 
frame rate display?

--TMIV

=======================================================================
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 May 12 13:54:38 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA13049 for info-performer-dist@holodeck.engr.sgi.com; Tue, 12 May 1998 13:36: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 NAA13022 for <info-performer@holodeck.engr.sgi.com>; Tue, 12 May 1998 13:36: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 NAA24013089
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 12 May 1998 13:36:10 -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 NAA19879
	for <info-performer@sgi.com>; Tue, 12 May 1998 13:36:09 -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 NAA24147355;
	Tue, 12 May 1998 13:36: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 NAA04504; Tue, 12 May 1998 13:36:07 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <3558B2B7.C1F954FC@sgi.com>
Date: Tue, 12 May 1998 13:36:07 -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 Castellar <javier@sixty.engr.sgi.com>
CC: Liu Xiaoyan <liuxy@ihpc.nus.edu.sg>, info-performer@sgi.com
Subject: Re: any support for TKO?
References: <35580C5B.271E@ihpc.nus.edu.sg> <9805121025.ZM12824@sixty.engr.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Javier Castellar wrote:
> 
> On May 12,  4:46pm, Liu Xiaoyan wrote:
> > Subject: any support for TKO?
> > ( Sorry, this may not be Performer relative.)
> >
> > Can TKO be implemented on Onyx2 with 2 IR pipes?

> > Unluckily, later we were told by SGI local support that TKO cannot
> > be done on this Onyx2. No detailed reasons.
> 
> I am very surprised, in any case please ask for the reasons.
> If you have an Onyx2 with two pipes, you MUST be able to do it.

They probably saw it wasn't on the price list
and jumped to the wrong conclusion.

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 May 12 14:37:28 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA13243 for info-performer-dist@holodeck.engr.sgi.com; Tue, 12 May 1998 14:18: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 OAA13216 for <info-performer@holodeck.engr.sgi.com>; Tue, 12 May 1998 14:18: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 OAA24048297
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 12 May 1998 14:18:57 -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 OAA10222
	for <info-performer@sgi.com>; Tue, 12 May 1998 14:18:50 -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 QAA04633 for <info-performer@sgi.com>; Tue, 12 May 1998 16:18:48 -0500 (CDT)
Date: Tue, 12 May 1998 16:18:24 -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: pfGSetAttr behavior changed?
Message-ID: <Pine.SGI.3.96.980512160738.11080A-100000@sutcliffe.bgm.link.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O



I have had some bad problems with a pfGeoSet attribute array.

Pre-Perf 2.2MR, this code seemed to work OK:

  pfGSetAttr ( gs, PFGS_COORD3, PFGS_PER_VERTEX, alist, ilist ) ;

  <lots more code>

  pfGSetAttr ( gs, PFGS_COORD3, PFGS_PER_VERTEX, different_alist, ilist ) ;

...the actual intent was to change the vertex attribute list
from a simple pfMalloc'ed array to a pfCycleBuffer'ed array containing
the exact same data.

Well, with Perf2.2 MR, my code is behaving very strangely - as though
the GeoSet hadn't noticed that different_alist is a pfCycleBuffer
and was treating it as a simple pfMalloc'ed array.

I RTFM'ed pfCycleBuffer (and was horrified to find it is now
'OBSOLETE') - rewrote the code using a pfFlux (as recommended on
the pfFlux man page) and discovered that this didn't seem to help -
although it did change the symptoms a tiny bit.

After a *lot* of messing around, printing addresses and prodding
the system in various ways, I discovered that this seemed to work:

  pfGSetAttr ( gs, PFGS_COORD3, PFGS_PER_VERTEX, alist, ilist ) ;

  <lots more code>

  pfGSetAttr ( gs, PFGS_COORD3, PFGS_PER_VERTEX, NULL, NULL ) ;
  pfGSetAttr ( gs, PFGS_COORD3, PFGS_PER_VERTEX, different_alist, ilist ) ;

It looks like presenting the GeoSet with NULL parameters is enough to
reset it's internal ideas about what kind of alist data it has.

Is this a pfBug or expected behavior?

If it's a bug then is this workaround appropriate?


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 May 12 17:00:17 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA26659 for info-performer-dist@holodeck.engr.sgi.com; Tue, 12 May 1998 16:41: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 QAA26632 for <info-performer@holodeck.engr.sgi.com>; Tue, 12 May 1998 16:41: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 QAA24000714
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 12 May 1998 16:41:17 -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 QAA07110
	for <info-performer@sgi.com>; Tue, 12 May 1998 16:41:16 -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 TAA13004;
	Tue, 12 May 1998 19:41:15 -0400 (EDT)
Received: (from kbrussel@localhost) by komodo-dragon.media.mit.edu (950413.SGI.8.6.12/8.6.11) id XAA19232; Tue, 12 May 1998 23:41:14 GMT
Date: Tue, 12 May 1998 23:41:14 GMT
Message-Id: <199805122341.XAA19232@komodo-dragon.media.mit.edu>
From: Kenneth B Russell <kbrussel@media.mit.edu>
To: Performer Enthusiasts <info-performer@sgi.com>
Subject: Shadow bug
Reply-to: kbrussel@media.mit.edu
Status: O


We're using the pfLightSource mechanism on an Onyx2 with iR
graphics to generate shadows in our application. We have found
that with certain camera positions, some garbage geometry appears
to be creating a shadow; by moving the camera slightly, the
effect goes away. See http://www.media.mit.edu/~kbrussel/shadowbug.html.
The problem is extremely dependent on window size; making the
window bigger changes the position for which the bug occurs.

Angus Dorbie suggested the last time I asked this that we might
be generating wrong LODs for certain geometry; now that we've got
things integrated in our application, though, I don't think this
is the cause. First, we have a custom loader, and I know I'm not
generating any LODs; second, the effect seems to be dependent on
camera position in a fine rather than a gross sense. That is, the
bug only appears when the camera enters certain small regions of
space (and not necessarily when it's in the shadow frustum).

Has anyone seen this before? Do we need to patch our machine? It
has been a while since we installed a patch set, because the last
one we tried caused a kernel panic upon bootup, and we haven't
had the potential few days to track that problem down.

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 May 12 17:37:05 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id RAA28814 for info-performer-dist@holodeck.engr.sgi.com; Tue, 12 May 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 RAA28787 for <info-performer@holodeck.engr.sgi.com>; Tue, 12 May 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 RAA23545378
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 12 May 1998 17:14:25 -0700 (PDT)
Received: from remi.engr.sgi.com ([150.166.37.25]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id RAA19033
	for <info-performer@sgi.com>; Tue, 12 May 1998 17:14:22 -0700 (PDT)
	mail_from (remi@remi.engr.sgi.com)
Received: (from remi@localhost) by remi.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id RAA20268; Tue, 12 May 1998 17:14:20 -0700
From: remi@remi.engr.sgi.com (Rémi Arnaud)
Message-Id: <199805130014.RAA20268@remi.engr.sgi.com>
Subject: Re: Shadow bug
To: kbrussel@media.mit.edu
Date: Tue, 12 May 1998 17:14:20 -0700 (PDT)
Cc: info-performer@sgi.com
In-Reply-To: <199805122341.XAA19232@komodo-dragon.media.mit.edu> from "Kenneth B Russell" at May 12, 98 11:41:14 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

Kenneth B Russell wrote:
> 
> 
> We're using the pfLightSource mechanism on an Onyx2 with iR
> graphics to generate shadows in our application. We have found
> that with certain camera positions, some garbage geometry appears
> to be creating a shadow; by moving the camera slightly, the
> effect goes away. See http://www.media.mit.edu/~kbrussel/shadowbug.html.
> The problem is extremely dependent on window size; making the
> window bigger changes the position for which the bug occurs.
> 
> Angus Dorbie suggested the last time I asked this that we might
> be generating wrong LODs for certain geometry; now that we've got
> things integrated in our application, though, I don't think this
> is the cause. First, we have a custom loader, and I know I'm not
> generating any LODs; second, the effect seems to be dependent on
> camera position in a fine rather than a gross sense. That is, the
> bug only appears when the camera enters certain small regions of
> space (and not necessarily when it's in the shadow frustum).
> 
> Has anyone seen this before? Do we need to patch our machine? It
> has been a while since we installed a patch set, because the last
> one we tried caused a kernel panic upon bootup, and we haven't
> had the potential few days to track that problem down.

 It depends how old are your patches. 1927 for example include some
 improvement in the microcode that does the 'Z' computation that
 can have a direct impact on the quality of the shadows.

> 
> 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
> 

    _  /              _             _ 
   |_) _ ._ _ 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 May 12 18:21:42 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id RAA29040 for info-performer-dist@holodeck.engr.sgi.com; Tue, 12 May 1998 17:48:05 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id RAA29011 for <info-performer@holodeck.engr.sgi.com>; Tue, 12 May 1998 17:48: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 RAA24146022
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 12 May 1998 17:44:03 -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 RAA28539
	for <info-performer@sgi.com>; Tue, 12 May 1998 17:44:02 -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 RAA24012692;
	Tue, 12 May 1998 17:44:02 -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 RAA04883; Tue, 12 May 1998 17:44:01 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <3558ECD1.2F9B4F36@sgi.com>
Date: Tue, 12 May 1998 17:44:01 -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: Shadow bug
References: <199805122341.XAA19232@komodo-dragon.media.mit.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Kenneth B Russell wrote:
> 
> We're using the pfLightSource mechanism on an Onyx2 with iR
> graphics to generate shadows in our application. We have found
> that with certain camera positions, some garbage geometry appears
> to be creating a shadow; by moving the camera slightly, the
> effect goes away. See http://www.media.mit.edu/~kbrussel/shadowbug.html.
> The problem is extremely dependent on window size; making the
> window bigger changes the position for which the bug occurs.
> 
> Angus Dorbie suggested the last time I asked this that we might
> be generating wrong LODs for certain geometry; now that we've got
> things integrated in our application, though, I don't think this
> is the cause. First, we have a custom loader, and I know I'm not
> generating any LODs; second, the effect seems to be dependent on
> camera position in a fine rather than a gross sense. That is, the
> bug only appears when the camera enters certain small regions of
> space (and not necessarily when it's in the shadow frustum).
> 
> Has anyone seen this before? Do we need to patch our machine? It
> has been a while since we installed a patch set, because the last
> one we tried caused a kernel panic upon bootup, and we haven't
> had the potential few days to track that problem down.
> 
> Thanks very much,
> 

Have you looked at what you are drawing to the shadow map channel?
Try checking this to see if there is anything undesirable appearing
there.

depth buffer clearing is also important. Are there any transparent
polygons in the scene which might be causing the occultation in the
depth buffer image?

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 May 12 19:28:44 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id TAA01338 for info-performer-dist@holodeck.engr.sgi.com; Tue, 12 May 1998 19:18: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 TAA01311 for <info-performer@holodeck.engr.sgi.com>; Tue, 12 May 1998 19:18: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 TAA22575517
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 12 May 1998 19:18:44 -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 TAA25310; Tue, 12 May 1998 19:18:41 -0700 (PDT)
	mail_from (kbrussel@media.mit.edu)
Received: from ongar.media.mit.edu (ongar.media.mit.edu [18.85.16.82])
	by aleve.media.mit.edu (8.8.7/ML970927) with ESMTP id WAA03251;
	Tue, 12 May 1998 22:18:40 -0400 (EDT)
Received: (from kbrussel@localhost) by ongar.media.mit.edu (8.8.6/8.7.3) id WAA16627; Tue, 12 May 1998 22:18:40 -0400 (EDT)
Date: Tue, 12 May 1998 22:18:40 -0400 (EDT)
Message-Id: <199805130218.WAA16627@ongar.media.mit.edu>
From: Kenneth B Russell <kbrussel@media.mit.edu>
To: Angus Dorbie <dorbie@sgi.com>
Cc: Performer Enthusiasts <info-performer@sgi.com>
In-reply-to: <3558ECD1.2F9B4F36@sgi.com> (message from Angus Dorbie on Tue, 12
	May 1998 17:44:01 -0700)
Subject: Re: Shadow bug
Reply-to: kbrussel@media.mit.edu
Status: O


> Have you looked at what you are drawing to the shadow map channel?
> Try checking this to see if there is anything undesirable appearing
> there.

I haven't checked this yet, though I'd guess the bogus shadow is
showing up in the shadow map. If I cover part of the window
during rendering, for example, I see a bogus shadow corresponding
to the occluded region; so I would guess that something (the
hardware, or some Performer internals) think there is a piece of
geometry there.

> depth buffer clearing is also important. Are there any transparent
> polygons in the scene which might be causing the occultation in the
> depth buffer image?

No, not in that scene. Again, the reason it's strange is that it
only occurs for some camera positions and viewing angles. From a
little testing, it looks like it's happening when the camera is
either facing (close to) the direction of the shadow frustum, or
is orthogonal to it. Zooming in/out changes the behavior as well.

Incidentally, I saw this problem the first time with the stock
shadows.c example when loading certain files out of
/usr/share/Performer/data; I'll have to check which ones. In that
example the camera wasn't moving but the light source was, and
occasionally a big dark square would appear in place of the
shadow. I can probably provide a screen shot tomorrow.

-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 May 12 19:28:42 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id TAA01305 for info-performer-dist@holodeck.engr.sgi.com; Tue, 12 May 1998 19:15: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 TAA01278 for <info-performer@holodeck.engr.sgi.com>; Tue, 12 May 1998 19:15: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 TAA24171598
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 12 May 1998 19:15:15 -0700 (PDT)
Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id TAA24642
	for <info-performer@sgi.com>; Tue, 12 May 1998 19:15:10 -0700 (PDT)
	mail_from (Graeme.Simpkin@dsto.defence.gov.au)
Received: from exchvic1.dsto.defence.gov.au (exchvic1.dsto.defence.gov.au [146.221.39.76]) by digger1.defence.gov.au (8.7.5/8.7.3) with ESMTP id LAA04665 for <info-performer@sgi.com>; Wed, 13 May 1998 11:42:43 +0930 (CST)
Received: by exchvic1.dsto.defence.gov.au with Internet Mail Service (5.5.1960.3)
	id <K5DAN677>; Wed, 13 May 1998 12:15:02 +1000
Message-ID: <5F23E32C8967D111A5D10000F81F6DE11F0963@exchvic2.dsto.defence.gov.au>
From: "Simpkin, Graeme" <Graeme.Simpkin@dsto.defence.gov.au>
To: "'info-performer@sgi.com'" <info-performer@sgi.com>
Cc: "Fulton, John" <john.fulton@dsto.defence.gov.au>,
        "Kerton, Ian"
	 <Ian.Kerton@dsto.defence.gov.au>
Subject: Performer 2.2 hanging in multichannel multipipe
Date: Wed, 13 May 1998 12:15:07 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Status: O

Please excuse me if this has already been discussed on this list.  I
could not find anything anything in the FAQ and the monthly archives
seem to stop at November of last year.

Our problem is this:
After upgrading from Performer 2.1 to 2.2 on a three pipe IR running
Irix 6.4, we have discovered a curious feature.  When running performer
apps on the console (eg: out of channel 0, single channel per pipe) we
are able to run as advertised (incl. multi-pipe).  However when we
reconfigure the graphics so that we run multiple channels out of each
pipe (using some combination of channels 1-7 say) the performer
application hangs while initialising the pipe window.  This happens for
all performer apps to my knowledge.  The following is a call stack dump
from perfly - when run with the -M0 -m0 options - showing the hangpoint.

pfVideoChannel::setId(<stripped>) ["pfVideoChannel.C":587]
pfPipeVideoChannel::nb_setId() ["pfPipeVideoChannel.C":487]
pfPipeWindow::pf_assignPVChanIds() ["pfPipeWindow.C":1758]
pfPipeWindow::nb_setScreen() ["pfPipeWindow.C":524]
pfPipeWindow::pf_openWin() ["pfPipeWindow.C":2455]
pfPipeWindow::nb_open(<stripped>) ["pfPipeWindow.C":639]
pfOpenPWin(<stripped>) ["cPipeWindow.C":1218]
pfuGLXWinopen(<stripped>) ["xwin.c":252]
OpenXWin(<stripped>) ["generic.c":831]
pfPipeWindow::pf_callConfigFunc() ["pfPipeWindow.C":2594]
pfPipeWindow::pf_updateOpenStatus() ["pfPipeWindow.C":966]
appCullDraw() ["pfProcess.C":3884]
pfFrame() ["pfProcess.C":4400]
main(<stripped>) ["main.c":132]
__start(<stripped>) ["crt1text.s":166]

Our application ran fine under Performer 2.1.  The above occurs if there
is a window manager running or not.
We have installed the suggested kernel rollup patch 2839.

Have people solved this problem ?  Is there a patch we have overlooked ?
Should we give up now ?

Thanks in anticipation,
Graeme Simpkin
graeme.simpkin@dsto.defence.gov.au
DSTO Australia

=======================================================================
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 May 13 01:45:47 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id BAA01961 for info-performer-dist@holodeck.engr.sgi.com; Wed, 13 May 1998 01: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 BAA01934 for <info-performer@holodeck.engr.sgi.com>; Wed, 13 May 1998 01:28: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 BAA17645609
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 13 May 1998 01:28:51 -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 BAA13371
	for <info-performer@sgi.com>; Wed, 13 May 1998 01:28:34 -0700 (PDT)
	mail_from (Ruddle@cardiff.ac.uk)
Received: from thor.cf.ac.uk by crane.cf.ac.uk with SMTP-LOC (PP);
          Wed, 13 May 1998 09:24:06 +0100
Received: from localhost (saprar@localhost) by thor.cf.ac.uk (8.8.8/8.6.12) 
          with SMTP id JAA15460 for <info-performer@sgi.com>;
          Wed, 13 May 1998 09:28:11 +0100 (BST)
Date: Wed, 13 May 1998 09:28:11 +0100 (BST)
From: Roy Ruddle <Ruddle@cardiff.ac.uk>
Reply-To: Ruddle@cardiff.ac.uk
To: info-performer@sgi.com
Subject: Mouse control
Message-ID: <Pine.OSF.3.95q.980513092320.21864B-100000@thor>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

Hi there,

I'm trying to control the position of the mouse from within a PF2.2
application, running in OpenGL. Functions like pfuDrawPWin2DCursor() draw
a cursor in a PWin but they don't affect the position of the mouse. I know
how to do that in GL (setvaluator( MOUSEX,  etc. )). Can anyone give me a
clue as to how I do it in OpenGL? Do I have to go through X, or can I use 
a pfuXXX function?

many thanks

roy

------------------------------------------------------------------------
Roy Ruddle, Senior Research Associate
Cardiff Virtual Environment Laboratory
School of Psychology, Cardiff University, PO Box 901, Cardiff CF1 3YG
Tel: +44 (0) 1222 874000 x5030, Fax: +44 (0) 1222 874858
Email: Ruddle@CARDIFF.AC.UK     http://www.cf.ac.uk/uwc/psych/ruddle/

=======================================================================
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 May 13 02:47:11 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id CAA02221 for info-performer-dist@holodeck.engr.sgi.com; Wed, 13 May 1998 02:30: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 CAA02194 for <info-performer@holodeck.engr.sgi.com>; Wed, 13 May 1998 02:30: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 CAA23225647
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 13 May 1998 02:30:37 -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 CAA24765
	for <info-performer@sgi.com>; Wed, 13 May 1998 02:30:25 -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.8/8.8.8) with SMTP id KAA11337
	for <info-performer@sgi.com>; Wed, 13 May 1998 10:30:21 +0100 (BST)
	(envelope-from nga@division.co.uk)
Received: by nga.division.co.uk with Microsoft Mail
	id <01BD7E5A.1B0041C0@nga.division.co.uk>; Wed, 13 May 1998 10:30:10 +0100
Message-ID: <01BD7E5A.1B0041C0@nga.division.co.uk>
From: Andrew Ng <nga@division.co.uk>
To: "'kbrussel@media.mit.edu'" <kbrussel@media.mit.edu>
Cc: Performer Enthusiasts <info-performer@sgi.com>
Subject: RE: Shadow bug
Date: Wed, 13 May 1998 10:30:09 +0100
Encoding: 17 TEXT
Status: O

> We're using the pfLightSource mechanism on an Onyx2 with iR
> graphics to generate shadows in our application. We have found
> that with certain camera positions, some garbage geometry appears
> to be creating a shadow; by moving the camera slightly, the
> effect goes away.

I have also been using pfLightSource shadows on our Onyx iR (which has 
patch 1808 installed) and have noticed the anomalies that you describe. The 
only explanation I can think of is that the floor geometry is actually 
shadowing itself in these situations. I had a quick go with different 
values for the shadow displace and scale but couldn't come up with a 
satisfactory set up.
--------------------------------------------------------------------------
  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  Wed May 13 06:17:20 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id FAA02599 for info-performer-dist@holodeck.engr.sgi.com; Wed, 13 May 1998 05:59: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 FAA02572 for <info-performer@holodeck.engr.sgi.com>; Wed, 13 May 1998 05:59: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 FAA23347440
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 13 May 1998 05:59:14 -0700 (PDT)
Received: from stigma.it (www.stigma.it [194.243.61.3]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id FAA06761
	for <info-performer@sgi.com>; Wed, 13 May 1998 05:59:09 -0700 (PDT)
	mail_from (conconi@stigma.it)
Received: from stigma.it
	by stigma.it (8.8.7/8.8.7) with ESMTP id PAA23727;
	Wed, 13 May 1998 15:00:12 +0200 (MET DST)
Message-ID: <35599846.794213A9@stigma.it>
Date: Wed, 13 May 1998 14:55:35 +0200
From: Stefano Conconi <conconi@stigma.it>
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: info-vega@paradigmsim.com
CC: info-performer@sgi.com
Subject: Euler angles
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Hi,
Could some one tell me somethinghs about the transformation between

Euler parameters - Euler angles- Yaw Pitch and Roll

for the orientation of an object?

Which algorithms I can use to do this transformation?

Or where can I find some usefull links about all of this kind of
orientation rappresentation?
--
-----------------------------------------------------------------
 Ing. Stefano Conconi
                        STIGMA On-Line S.r.l.
                        PAVIA  - Italy
-----------------------------------------------------------------
E-Mail: conconi@stigma.it    Phone:  +39 (0382) 578948-9
WWW: http://www.stigma.it    Fax:    +39 (0382) 577902


=======================================================================
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 May 13 07:19:04 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA02818 for info-performer-dist@holodeck.engr.sgi.com; Wed, 13 May 1998 07:03: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 HAA02791 for <info-performer@holodeck.engr.sgi.com>; Wed, 13 May 1998 07:03: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 HAA24071247
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 13 May 1998 07:03:12 -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 HAA25467
	for <info-performer@sgi.com>; Wed, 13 May 1998 07:03:07 -0700 (PDT)
	mail_from (ach@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 QAA04084
	for <info-performer@sgi.com>; Wed, 13 May 1998 16:03:04 +0200 (MET DST)
Received: by anna.internet.syseca (940816.SGI.8.6.9/930416.SGI)
	for info-performer@sgi.com id QAA15107; Wed, 13 May 1998 16:02:03 +0200
From: "Laurent Ach" <ach@syseca.fr>
Message-Id: <9805131602.ZM15105@anna.internet.syseca>
Date: Wed, 13 May 1998 16:02:02 -0600
X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail)
To: info-performer@sgi.com
Subject: flt loader backward compatibility
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

Hi,

I think I saw some messages about problems in Performer backward compatibility
(release 2.2 -> 2.1) regarding flt loader. Unfortunately, at that time I was
not interested in this question, but now it would be nice if someone could tell
me how to run an application built with Performer 2.1 and using the flt loader,
in a Performer 2.2 execution environment. Because the loader can't be found
event with the compatibility DSO installed.

By the way, I could not manage to find recent mailing list archives at SGI ftp
site (ftp://sgigate.sgi.com/pub/Performer/monthly-archives/), the last ones
being from november 1997.

Thanks,

Laurent


-- 
--------------------------------------------------------------------
Laurent Ach                              tel :  33 (0) 1 41 48 06 60
SYSECA                                   fax :  33 (0) 1 41 48 06 81
ach@syseca.fr
http://www.syseca.thomson-csf.com/english/cha1/SDA.HTM
--------------------------------------------------------------------
=======================================================================
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 May 13 09:19:36 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA03240 for info-performer-dist@holodeck.engr.sgi.com; Wed, 13 May 1998 09:05: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 JAA03213 for <info-performer@holodeck.engr.sgi.com>; Wed, 13 May 1998 09:05:15 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA35566
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 13 May 1998 09:04:49 -0700 (PDT)
Received: from acusoft.com (acusoft.acusoft.com [205.187.235.130]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id JAA10295; Wed, 13 May 1998 09:04:30 -0700 (PDT)
	mail_from (miller@acusoft.com)
Received: from marvin by acusoft.com (5.x/SMI-SVR4)
	id AA20753; Wed, 13 May 1998 12:04:24 -0400
Received: by marvin (950413.SGI.8.6.12) id MAA02763; Wed, 13 May 1998 12:04:22 -0400
Date: Wed, 13 May 1998 12:04:22 -0400 (EDT)
From: "Thomas M. Miller" <miller@acusoft.com>
X-Sender: miller@marvin
To: src@rose.engr.sgi.com, dorbie@sgi.com, info-performer@sgi.com
Cc: liu@acusoft.com, lyou@acusoft.com
Subject: More Info - Re: inf/60.0 (fwd)
Message-Id: <Pine.SGI.3.91.980513120217.2728B-101000@marvin>
Mime-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-843322490-819139725-895075462=:2728"
Status: O

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

---843322490-819139725-895075462=:2728
Content-Type: TEXT/PLAIN; charset=US-ASCII


I forgot to attach the vfo to my last email.
It is attached to this one.

--TMIV

---843322490-819139725-895075462=:2728
Content-Type: APPLICATION/octet-stream; name="1024x768_180sq.vfo"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.SGI.3.91.980513120422.2728C@marvin>
Content-Description: 

AAAABHNkYiAAAAAAAAAAAQAAAAAAAAABAAAAZFZpZGVvRm9ybWF0Q29tcGls
ZXIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC+AAAA
AAAALHAAAAAAAAADAAAABABBgSqIAAAAAEFoy6gAAAAAAAAABgAAAAYAAAMA
AAADAAAAAwAAAAMAAAADAAAAAwAAAAAGAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAAAABAAAAAAAA
AAAAAAABAAAAAAAAAAAAAAAGAAAAAQAAAAIAAAAEAAAAAQAAAAIAAAAEAAAA
BgAAAAIAAAACAAAAAgAAAAEAAAABAAAAAQAAACZTdGVyZW8gRmllbGQgU2Vx
dWVudGlhbCAxMDI0eDc2OF8xODBzcQAAQD4AAAAAAAAAAAABPqXnH7YZzBE+
jTQqW1w0fz6dNCpbXDR/PtzWtpuSRxUAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAABBgLB2AAAAAAAAAAAAAAAAP6EREREREREAAAAC
AAAS8AAABPBAPgAAAAAAAD/QAAAAAAAAAAAABAAAAAFBZuNgAAAAAAAAAAAA
AAAQAAAAAAAAH/8AAAEAAAAAIAAAB/8AAAABAAAAMgAAAAEAAAAAAAAAAAAA
AAE+ZXmO4jCMOgAAEAAAAAADAAAACkGH14QAAAAAQXfXhAAAAABBZ9eEAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAIAAAAAVDU1lOQwAAAAAAAAoAAAAAAAAAAQAAAAIA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC1ZPQyBmb3IgREc0AAAA
AAAAAAAAAAAAESRSZXZpc2lvbjogMS40NSAkAAAAPqQT3Rs0jUQ+lecfthnM
EQAAAAIAAAABAAAADgAAAA4AAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAAB
AAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAA4AAAACAAAAAgAAAAIA
AAABAAAAAQAAAAEAAAACAAAAAQAAAAEAAAABAAAAAgAAAAEAAAABAAAAAQAA
AA9UcmFuc2l0aW9uVmFsaWQAAAAAD1RyYW5zaXRpb25WYWx1ZQAAAAATVHJh
bnNpdGlvbkRpcmVjdGlvbgAAAAAcVHJhbnNpdGlvbkxpbmVUeXBlc1VzaW5n
JTA1ZAAAACAAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEA
AAABAAAAAQAAAAEAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAACAAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAAB
AAAAAQAAAAEAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAB
AAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAEA
AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAABAAAAAQAAAAEAAAAB
AAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAA
AQAAAAEAAAABAAAAAQAAAAEAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAABAAAAAQAAAAEAAAABAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAABAAAAAQAAAAAAAAABAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAACAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAABAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAACAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ACAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAA
AAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAABAAAAAQAAAAEAAAABAAAAAQAA
AAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAACAAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEA
AAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAACAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAACAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ACAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAAAA
AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADIAAAABAAAA
AQAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAEAAAABAAAAAQAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAQAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAQAAAAEAAAABAAAAAAAAAAEAAAABAAAAAQAA
AAEAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAEAAAAAAAAAAAAAAAEAAAABAAAA
AQAAAAEAAAABAAAAAAAAADIAAAAAAAAAFAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAUAAABKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMgAAATIA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATwAA
AO0AAAAAAAAAAAAAAE8AAADtAAAAJQAAASUAAAAAAAAAAAAAAAAAAAAAAAAA
CQAAAB0AAAAAAAAAAAAAAAAAAAAzAAAAAAAAAC4AAAAAAAAAAAAAADIAAAAB
AAAAAgAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAgAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAgAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAEAAAABAAAAAAAAAAIAAAABAAAA
AgAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAEAAAAAAAAAAAAAAAIAAAAB
AAAAAgAAAAEAAAACAAAAAAAAAQAAAAAAAAAAAQAAAAIAAAADAAAAAgAAAAQA
AAAFAAAABgAAAAUAAAAHAAAACAAAAAkAAAAKAAAAAgAAAAsAAAAFAAAABwAA
AAgAAAAJAAAACgAAAAIAAAALAAAABQAAAAcAAAAIAAAADAAAAAoAAAACAAAA
AwAAAAIAAAAEAAAABQAAAAYAAAAFAAAABwAAAAgAAAAJAAAACgAAAAIAAAAL
AAAABQAAAAcAAAAIAAAACQAAAAoAAAACAAAACwAAAAUAAAAHAAAACAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAABAAAAAAEAAAABAAAAAgAAAAEAAAABAAAAAQAAAAQAAAAB
AAAAGwAAAwAAAAABAAAAAQAAAAEAAAABAAAAAQAAACMAAAMAAAAAAQAAAAEA
AAABAAAAAQAAAAEAAAAjAAADAAAAAAEAAAABAAAAAQAAAAIAAAABAAAAAQAA
AAEAAAAEAAAAAQAAABsAAAMAAAAAAQAAAAEAAAABAAAAAQAAAAEAAAAjAAAD
AAAAAAEAAAABAAAAAQAAAAEAAAABAAAAIwAAAwAAAAABAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAyAAABAAAAACAAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAA
AQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAACAAAAE8AAABPAAAATwAAAE8AAABPAAAATwAAAE8AAABPAAA
ATwAAAE8AAABPAAAATwAAAE8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAADIAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEA
AAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAA
AAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAA
AQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAAB
AAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAADIAAAAAAAAAAAAAAAAA
AAAAAAAAAQAAAAEAAAABAAAAAQAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAA
AAIAAAACAAAAAwAAAAMAAAADAAAAAwAAAAMAAAADAAAABAAAAAQAAAAEAAAA
BAAAAAQAAAAEAAAABQAAAAUAAAAGAAAABgAAAAcAAAAHAAAACAAAAAgAAAAI
AAAACAAAAAgAAAAIAAAACQAAAAkAAAAKAAAACgAAAAsAAAALAAAADAAAAAwA
AAANAAAADQAAAAAAAAABAAAAAgAAAAMAAAAAAAAACwAAAYAAAAABAAAAIAAA
AAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEu8K
9R4AAAAAeAAAAFAAAAAoAAAD/wAAEgAAAAAAAAADAAAAovAAAB2gAAAEoAAO
0AAAAATwAAADAAAAscAAAA7QAAAEoAAO0AAAAATwAAADAAAAscAAAA7QAAAE
oAAO0AAAAATwAAADAAAAovAAAB2gAAAEoAAO0AAAAATwAAADAAAAscAAAA7Q
AAAEoAAO0AAAAATwAAADAAAAscAAAA7QAAAEoAAO0AAAAATwAAAAvgAAABJB
Y3RpdmVCbGFua2luZ0xlZnQAAAAAAAIAAAAAAAACbAAAABNBY3RpdmVCbGFu
a2luZ1JpZ2h0AAAAAAIAAAAAAAACcAAAABNBY3RpdmVMaW5lc1BlckZyYW1l
AAAAAAIAAAAAAAAAkAAAABNBY3RpdmVQaXhlbHNQZXJMaW5lAAAAAAIAAAAA
AAAAlAAAAAlCZWdpblRpbWUAAAAAAAARAAAAAAAAAggAAAAVQ29ycmVzcG9u
ZGluZ1BvbGFyaXR5AAAAAAAAAgAAAAAAAAIYAAAADkRBQ1JhdGVNYXhpbXVt
AAAAAAARAAAAAAAAAJgAAAAOREFDUmF0ZU1pbmltdW0AAAAAABEAAAAAAAAA
oAAAABlFZGdlU2lnbmFsQXNzaWdubWVudFZhbGlkAAAAAAAAAgAAADIAACmA
AAAAGUVkZ2VTaWduYWxBc3NpZ25tZW50VmFsdWUAAAAAAAACAAAAMgAAKkwA
AAAHRW5kVGltZQAAAAARAAAAAAAAAhAAAAAQRmV0Y2hFeHRyYUNsb2NrcwAA
AAIAAAAAAAACYAAAAApGaWVsZENvbG9yAAAAAAACAAAABgAAARwAAAARRmll
bGRDb3VudE1heGltdW0AAAAAAAACAAAAAAAAAkgAAAAIRmllbGRFeWUAAAAC
AAAABgAAATgAAAAORmllbGRMaW5lQ291bnQAAAAAAAIAAAAGAAAArAAAAA9G
aWVsZExpbmVPZmZzZXQAAAAAAgAAAAYAAADIAAAADUZpZWxkTGluZVNraXAA
AAAAAAACAAAABgAAAOQAAAAJRmllbGRTd2FwAAAAAAAAAgAAAAYAAAEAAAAA
DkZpZWxkc1BlckZyYW1lAAAAAAACAAAAAAAAAKgAAAAYRm9ybWF0SW5mb19B
Y3RpdmVGQkxpbmVzAAAAAgAAAAAAACvcAAAAHUZvcm1hdEluZm9fQWN0aXZl
TW9uaXRvckxpbmVzAAAAAAAAAgAAAAAAACvYAAAAHkZvcm1hdEluZm9fRl8w
X0FjdGl2ZUxpbmVDb3VudAAAAAAAAgAAAAAAACvgAAAAF0Zvcm1hdEluZm9f
Rl8wX1ZfQWN0aXZlAAAAAAIAAAAAAAAr8AAAABpGb3JtYXRJbmZvX0ZfMF9W
X0JhY2tQb3JjaAAAAAAAAgAAAAAAACvkAAAAG0Zvcm1hdEluZm9fRl8wX1Zf
RnJvbnRQb3JjaAAAAAACAAAAAAAAK/QAAAAVRm9ybWF0SW5mb19GXzBfVl9T
eW5jAAAAAAAAAgAAAAAAACvoAAAAGkZvcm1hdEluZm9fRl8wX1ZfU3luY1B1
bHNlAAAAAAACAAAAAAAAK+wAAAAeRm9ybWF0SW5mb19GXzFfQWN0aXZlTGlu
ZUNvdW50AAAAAAACAAAAAAAAK/gAAAAXRm9ybWF0SW5mb19GXzFfVl9BY3Rp
dmUAAAAAAgAAAAAAACwIAAAAGkZvcm1hdEluZm9fRl8xX1ZfQmFja1BvcmNo
AAAAAAACAAAAAAAAK/wAAAAbRm9ybWF0SW5mb19GXzFfVl9Gcm9udFBvcmNo
AAAAAAIAAAAAAAAsDAAAABVGb3JtYXRJbmZvX0ZfMV9WX1N5bmMAAAAAAAAC
AAAAAAAALAAAAAAaRm9ybWF0SW5mb19GXzFfVl9TeW5jUHVsc2UAAAAAAAIA
AAAAAAAsBAAAAB5Gb3JtYXRJbmZvX0ZfMl9BY3RpdmVMaW5lQ291bnQAAAAA
AAIAAAAAAAAsEAAAABdGb3JtYXRJbmZvX0ZfMl9WX0FjdGl2ZQAAAAACAAAA
AAAALCAAAAAaRm9ybWF0SW5mb19GXzJfVl9CYWNrUG9yY2gAAAAAAAIAAAAA
AAAsFAAAABtGb3JtYXRJbmZvX0ZfMl9WX0Zyb250UG9yY2gAAAAAAgAAAAAA
ACwkAAAAFUZvcm1hdEluZm9fRl8yX1ZfU3luYwAAAAAAAAIAAAAAAAAsGAAA
ABpGb3JtYXRJbmZvX0ZfMl9WX1N5bmNQdWxzZQAAAAAAAgAAAAAAACwcAAAA
HkZvcm1hdEluZm9fRl8zX0FjdGl2ZUxpbmVDb3VudAAAAAAAAgAAAAAAACwo
AAAAF0Zvcm1hdEluZm9fRl8zX1ZfQWN0aXZlAAAAAAIAAAAAAAAsOAAAABpG
b3JtYXRJbmZvX0ZfM19WX0JhY2tQb3JjaAAAAAAAAgAAAAAAACwsAAAAG0Zv
cm1hdEluZm9fRl8zX1ZfRnJvbnRQb3JjaAAAAAACAAAAAAAALDwAAAAVRm9y
bWF0SW5mb19GXzNfVl9TeW5jAAAAAAAAAgAAAAAAACwwAAAAGkZvcm1hdElu
Zm9fRl8zX1ZfU3luY1B1bHNlAAAAAAACAAAAAAAALDQAAAAeRm9ybWF0SW5m
b19GXzRfQWN0aXZlTGluZUNvdW50AAAAAAACAAAAAAAALEAAAAAXRm9ybWF0
SW5mb19GXzRfVl9BY3RpdmUAAAAAAgAAAAAAACxQAAAAGkZvcm1hdEluZm9f
Rl80X1ZfQmFja1BvcmNoAAAAAAACAAAAAAAALEQAAAAbRm9ybWF0SW5mb19G
XzRfVl9Gcm9udFBvcmNoAAAAAAIAAAAAAAAsVAAAABVGb3JtYXRJbmZvX0Zf
NF9WX1N5bmMAAAAAAAACAAAAAAAALEgAAAAaRm9ybWF0SW5mb19GXzRfVl9T
eW5jUHVsc2UAAAAAAAIAAAAAAAAsTAAAAB5Gb3JtYXRJbmZvX0ZfNV9BY3Rp
dmVMaW5lQ291bnQAAAAAAAIAAAAAAAAsWAAAABdGb3JtYXRJbmZvX0ZfNV9W
X0FjdGl2ZQAAAAACAAAAAAAALGgAAAAaRm9ybWF0SW5mb19GXzVfVl9CYWNr
UG9yY2gAAAAAAAIAAAAAAAAsXAAAABtGb3JtYXRJbmZvX0ZfNV9WX0Zyb250
UG9yY2gAAAAAAgAAAAAAACxsAAAAFUZvcm1hdEluZm9fRl81X1ZfU3luYwAA
AAAAAAIAAAAAAAAsYAAAABpGb3JtYXRJbmZvX0ZfNV9WX1N5bmNQdWxzZQAA
AAAAAgAAAAAAACxkAAAAE0Zvcm1hdEluZm9fSF9BY3RpdmUAAAAAAgAAAAAA
ACvUAAAAFkZvcm1hdEluZm9fSF9CYWNrUG9yY2gAAAAAAAIAAAAAAAAryAAA
ABdGb3JtYXRJbmZvX0hfRnJvbnRQb3JjaAAAAAACAAAAAAAAK9AAAAARRm9y
bWF0SW5mb19IX1N5bmMAAAAAAAACAAAAAAAAK8wAAAAVRm9ybWF0SW5mb19Q
aXhlbENsb2NrAAAAAAAAAgAAAAAAACvEAAAACkZvcm1hdE5hbWUAAAAAAA8A
AAAAAAABVAAAABFGcmFtZVBvcnRpb25JbmRleAAAAAAAAAIAAAAAAAABiAAA
AA9GcmFtZXNQZXJTZWNvbmQAAAAAEQAAAAAAAAGAAAAAFUhCYWNrUG9yY2hD
bGFtcExlbmd0aAAAAAAAABEAAAAAAAADUAAAABRIQmFja1BvcmNoQ2xhbXBT
dGFydAAAABEAAAAAAAADSAAAABNIb3Jpem9udGFsQmFja1BvcmNoAAAAABEA
AAAAAAABjAAAABRIb3Jpem9udGFsRnJvbnRQb3JjaAAAABEAAAAAAAABlAAA
AA5Ib3Jpem9udGFsU3luYwAAAAAAEQAAAAAAAAGcAAAAEUxpbmVMZW5ndGhN
YXhpbXVtAAAAAAAAAgAAAAAAAAJQAAAADkxpbmVMZW5ndGhUaW1lAAAAAAAR
AAAAAAAAAaQAAAANTGluZVR5cGVDb3VudAAAAAAAAAIAAAAAAAACWAAAAA5M
aW5lVHlwZUxlbmd0aAAAAAAAAgAAACAAACj8AAAADUxpbmVUeXBlVmFsaWQA
AAAAAAACAAAAIAAAKHgAAAAXTW9uaXRvckZyYW1lUmF0ZU1heGltdW0AAAAA
EQAAAAAAAAGsAAAAF01vbml0b3JGcmFtZVJhdGVNaW5pbXVtAAAAABEAAAAA
AAABtAAAABZNb25pdG9yTGluZVJhdGVNYXhpbXVtAAAAAAARAAAAAAAAAbwA
AAAWTW9uaXRvckxpbmVSYXRlTWluaW11bQAAAAAAEQAAAAAAAAHEAAAAHk1v
bml0b3JWZXJ0aWNhbEJsYW5raW5nTWF4aW11bQAAAAAAEQAAAAAAAAHMAAAA
Hk1vbml0b3JWZXJ0aWNhbEJsYW5raW5nTWluaW11bQAAAAAAEQAAAAAAAAHU
AAAADk9sZFN0eWxlU3RlcmVvAAAAAAACAAAAAAAAAygAAAAOUEZEQ2xvY2tT
ZWxlY3QAAAAAAAIAAAAAAAArKAAAABBQRkRDbG9ja1NldHRpbmdzAAAAAgAA
AAoAAALsAAAADlBGRENsb2NrU3BlZWRzAAAAAAARAAAACgAAAogAAAAWUEZE
Q29tcGFyYXRvclByZWNpc2lvbgAAAAAAAgAAAAAAACssAAAADlBGRENvbnRy
b2xTaXplAAAAAAACAAAAAAAAAtwAAAAFUEZERVEAAAAAAAACAAAAAAAAKxgA
AAAFUEZER1QAAAAAAAACAAAAAAAAKyAAAAAJUEZESW52ZXJ0AAAAAAAAAgAA
AAAAACs0AAAABVBGRExUAAAAAAAAAgAAAAAAACscAAAAEFBGRE1heGltdW1D
bG9ja3MAAAACAAAAAAAAAoAAAAATUEZETWluaW11bVByZWNpc2lvbgAAAAAR
AAAAAAAAAngAAAARUEZETnVtQ2xvY2tTcGVlZHMAAAAAAAACAAAAAAAAAoQA
AAAPUEZEUmVndWxhckxpbmVzAAAAAAIAAAAAAAArMAAAABNQRkRTb3VyY2VT
aWduYWxOYW1lAAAAAA8AAAAAAAAC4AAAAAhQRkRUYWJsZQAAAAIAAAAgAAAr
OAAAAApQRkRUcmlnZ2VyAAAAAAACAAAAAAAAKyQAAAATUEZEVk9GVmVydGlj
YWxQaGFzZQAAAAACAAAAAAAAK8AAAAANUEZEVmFsaWRUYWJsZQAAAAAAAAIA
AAAAAAArvAAAABVQaXhlbEFjY3VyYXRlQmxhbmtpbmcAAAAAAAACAAAAAAAA
AmgAAAAaUHJvZ3JhbW1hYmxlRnJhbWVEZXRlY3Rpb24AAAAAAAIAAAAAAAAC
dAAAABRTZXJyYXRlZENTeW5jT25IU3luYwAAAAIAAAAAAAADLAAAABdTaWdu
YWxJbml0aWFsU3RhdGVWYWxpZAAAAAACAAAADgAAA2QAAAAXU2lnbmFsSW5p
dGlhbFN0YXRlVmFsdWUAAAAAAgAAAA4AAAOgAAAAFlN0YXRlUmVwZXRpdGlv
bk1heGltdW0AAAAAAAIAAAAAAAACXAAAABJTdGF0ZVRhYmxlTGluZVR5cGUA
AAAAAAIAAAEAAAAgaAAAABVTdGF0ZVRhYmxlUmVwZXRpdGlvbnMAAAAAAAAC
AAABAAAAJGwAAAAOU3RhdGVUYWJsZVNpemUAAAAAAAIAAAAAAAAodAAAABVT
dGF0ZVRhYmxlVmFsaWRTdGF0ZXMAAAAAAAACAAAAAAAAKHAAAAANU3dhcHNQ
ZXJGcmFtZQAAAAAAAAIAAAAAAAAB3AAAABZTeXN0ZW1GcmFtZVJhdGVNYXhp
bXVtAAAAAAARAAAAAAAAAeAAAAAWU3lzdGVtRnJhbWVSYXRlTWluaW11bQAA
AAAAEQAAAAAAAAHoAAAAFVN5c3RlbUxpbmVSYXRlTWF4aW11bQAAAAAAABEA
AAAAAAAB8AAAABVTeXN0ZW1MaW5lUmF0ZU1pbmltdW0AAAAAAAARAAAAAAAA
AfgAAAAbU3lzdGVtVmlkZW9DbG9ja1JhdGVNYXhpbXVtAAAAABEAAAAAAAAC
AAAAABtTeXN0ZW1WaWRlb0Nsb2NrUmF0ZU1pbmltdW0AAAAAEQAAAAAAAAI8
AAAADlRvdGFsRWRnZUNvdW50AAAAAAACAAAAAAAAAmQAAAASVG90YWxMaW5l
c1BlckZyYW1lAAAAAAACAAAAAAAAAhwAAAASVG90YWxQaXhlbHNQZXJMaW5l
AAAAAAACAAAAAAAAAiAAAAAQVG90YWxTaWduYWxDb3VudAAAAAIAAAAAAAAD
YAAAABNUcmFuc2l0aW9uRGlyZWN0aW9uAAAAAAIAAAAyAAAfnAAAABdUcmFu
c2l0aW9uRGlyZWN0aW9uSGlnaAAAAAACAAAAAAAAA1gAAAAWVHJhbnNpdGlv
bkRpcmVjdGlvbkxvdwAAAAAAAgAAAAAAAANcAAAAGlRyYW5zaXRpb25EaXJl
Y3Rpb25TdXBwb3J0AAAAAAACAAAAAAAAAkwAAAAdVHJhbnNpdGlvbkxpbmVU
eXBlc1VzaW5nMDAwMDAAAAAAAAAKAAAAIAAABDwAAAAdVHJhbnNpdGlvbkxp
bmVUeXBlc1VzaW5nMDAwMDEAAAAAAAAKAAAAIAAABMAAAAAdVHJhbnNpdGlv
bkxpbmVUeXBlc1VzaW5nMDAwMDIAAAAAAAAKAAAAIAAABUQAAAAdVHJhbnNp
dGlvbkxpbmVUeXBlc1VzaW5nMDAwMDMAAAAAAAAKAAAAIAAABcgAAAAdVHJh
bnNpdGlvbkxpbmVUeXBlc1VzaW5nMDAwMDQAAAAAAAAKAAAAIAAABkwAAAAd
VHJhbnNpdGlvbkxpbmVUeXBlc1VzaW5nMDAwMDUAAAAAAAAKAAAAIAAABtAA
AAAdVHJhbnNpdGlvbkxpbmVUeXBlc1VzaW5nMDAwMDYAAAAAAAAKAAAAIAAA
B1QAAAAdVHJhbnNpdGlvbkxpbmVUeXBlc1VzaW5nMDAwMDcAAAAAAAAKAAAA
IAAAB9gAAAAdVHJhbnNpdGlvbkxpbmVUeXBlc1VzaW5nMDAwMDgAAAAAAAAK
AAAAIAAACFwAAAAdVHJhbnNpdGlvbkxpbmVUeXBlc1VzaW5nMDAwMDkAAAAA
AAAKAAAAIAAACOAAAAAdVHJhbnNpdGlvbkxpbmVUeXBlc1VzaW5nMDAwMTAA
AAAAAAAKAAAAIAAACWQAAAAdVHJhbnNpdGlvbkxpbmVUeXBlc1VzaW5nMDAw
MTEAAAAAAAAKAAAAIAAACegAAAAdVHJhbnNpdGlvbkxpbmVUeXBlc1VzaW5n
MDAwMTIAAAAAAAAKAAAAIAAACmwAAAAdVHJhbnNpdGlvbkxpbmVUeXBlc1Vz
aW5nMDAwMTMAAAAAAAAKAAAAIAAACvAAAAAdVHJhbnNpdGlvbkxpbmVUeXBl
c1VzaW5nMDAwMTQAAAAAAAAKAAAAIAAAC3QAAAAdVHJhbnNpdGlvbkxpbmVU
eXBlc1VzaW5nMDAwMTUAAAAAAAAKAAAAIAAAC/gAAAAdVHJhbnNpdGlvbkxp
bmVUeXBlc1VzaW5nMDAwMTYAAAAAAAAKAAAAIAAADHwAAAAdVHJhbnNpdGlv
bkxpbmVUeXBlc1VzaW5nMDAwMTcAAAAAAAAKAAAAIAAADQAAAAAdVHJhbnNp
dGlvbkxpbmVUeXBlc1VzaW5nMDAwMTgAAAAAAAAKAAAAIAAADYQAAAAdVHJh
bnNpdGlvbkxpbmVUeXBlc1VzaW5nMDAwMTkAAAAAAAAKAAAAIAAADggAAAAd
VHJhbnNpdGlvbkxpbmVUeXBlc1VzaW5nMDAwMjAAAAAAAAAKAAAAIAAADowA
AAAdVHJhbnNpdGlvbkxpbmVUeXBlc1VzaW5nMDAwMjEAAAAAAAAKAAAAIAAA
DxAAAAAdVHJhbnNpdGlvbkxpbmVUeXBlc1VzaW5nMDAwMjIAAAAAAAAKAAAA
IAAAD5QAAAAdVHJhbnNpdGlvbkxpbmVUeXBlc1VzaW5nMDAwMjMAAAAAAAAK
AAAAIAAAEBgAAAAdVHJhbnNpdGlvbkxpbmVUeXBlc1VzaW5nMDAwMjQAAAAA
AAAKAAAAIAAAEJwAAAAdVHJhbnNpdGlvbkxpbmVUeXBlc1VzaW5nMDAwMjUA
AAAAAAAKAAAAIAAAESAAAAAdVHJhbnNpdGlvbkxpbmVUeXBlc1VzaW5nMDAw
MjYAAAAAAAAKAAAAIAAAEaQAAAAdVHJhbnNpdGlvbkxpbmVUeXBlc1VzaW5n
MDAwMjcAAAAAAAAKAAAAIAAAEigAAAAdVHJhbnNpdGlvbkxpbmVUeXBlc1Vz
aW5nMDAwMjgAAAAAAAAKAAAAIAAAEqwAAAAdVHJhbnNpdGlvbkxpbmVUeXBl
c1VzaW5nMDAwMjkAAAAAAAAKAAAAIAAAEzAAAAAdVHJhbnNpdGlvbkxpbmVU
eXBlc1VzaW5nMDAwMzAAAAAAAAAKAAAAIAAAE7QAAAAdVHJhbnNpdGlvbkxp
bmVUeXBlc1VzaW5nMDAwMzEAAAAAAAAKAAAAIAAAFDgAAAAdVHJhbnNpdGlv
bkxpbmVUeXBlc1VzaW5nMDAwMzIAAAAAAAAKAAAAIAAAFLwAAAAdVHJhbnNp
dGlvbkxpbmVUeXBlc1VzaW5nMDAwMzMAAAAAAAAKAAAAIAAAFUAAAAAdVHJh
bnNpdGlvbkxpbmVUeXBlc1VzaW5nMDAwMzQAAAAAAAAKAAAAIAAAFcQAAAAd
VHJhbnNpdGlvbkxpbmVUeXBlc1VzaW5nMDAwMzUAAAAAAAAKAAAAIAAAFkgA
AAAdVHJhbnNpdGlvbkxpbmVUeXBlc1VzaW5nMDAwMzYAAAAAAAAKAAAAIAAA
FswAAAAdVHJhbnNpdGlvbkxpbmVUeXBlc1VzaW5nMDAwMzcAAAAAAAAKAAAA
IAAAF1AAAAAdVHJhbnNpdGlvbkxpbmVUeXBlc1VzaW5nMDAwMzgAAAAAAAAK
AAAAIAAAF9QAAAAdVHJhbnNpdGlvbkxpbmVUeXBlc1VzaW5nMDAwMzkAAAAA
AAAKAAAAIAAAGFgAAAAdVHJhbnNpdGlvbkxpbmVUeXBlc1VzaW5nMDAwNDAA
AAAAAAAKAAAAIAAAGNwAAAAdVHJhbnNpdGlvbkxpbmVUeXBlc1VzaW5nMDAw
NDEAAAAAAAAKAAAAIAAAGWAAAAAdVHJhbnNpdGlvbkxpbmVUeXBlc1VzaW5n
MDAwNDIAAAAAAAAKAAAAIAAAGeQAAAAdVHJhbnNpdGlvbkxpbmVUeXBlc1Vz
aW5nMDAwNDMAAAAAAAAKAAAAIAAAGmgAAAAdVHJhbnNpdGlvbkxpbmVUeXBl
c1VzaW5nMDAwNDQAAAAAAAAKAAAAIAAAGuwAAAAdVHJhbnNpdGlvbkxpbmVU
eXBlc1VzaW5nMDAwNDUAAAAAAAAKAAAAIAAAG3AAAAAdVHJhbnNpdGlvbkxp
bmVUeXBlc1VzaW5nMDAwNDYAAAAAAAAKAAAAIAAAG/QAAAAdVHJhbnNpdGlv
bkxpbmVUeXBlc1VzaW5nMDAwNDcAAAAAAAAKAAAAIAAAHHgAAAAdVHJhbnNp
dGlvbkxpbmVUeXBlc1VzaW5nMDAwNDgAAAAAAAAKAAAAIAAAHPwAAAAdVHJh
bnNpdGlvbkxpbmVUeXBlc1VzaW5nMDAwNDkAAAAAAAAKAAAAIAAAHYAAAAAP
VHJhbnNpdGlvblZhbGlkAAAAAAIAAAAyAAAeBAAAAA9UcmFuc2l0aW9uVmFs
dWUAAAAAAgAAADIAAB7QAAAAE1ZlcnRpY2FsUmV0cmFjZVJhdGUAAAAAEQAA
AAAAAAIkAAAAElZlcnRpY2FsU3RhdGVDb3VudAAAAAAAAgAAAAAAAAJUAAAA
D1ZpZGVvQ2xvY2tSYXRpbwAAAAARAAAAAAAAAiwAAAAaVmlkZW9DbG9ja1Jh
dGlvRGVub21pbmF0b3IAAAAAAAIAAAAAAAACNAAAABhWaWRlb0Nsb2NrUmF0
aW9OdW1lcmF0b3IAAAACAAAAAAAAAjgAAAAPVm9mSGFyZHdhcmVOYW1lAAAA
AA8AAAAAAAADGAAAABpfVHJhbnNpdGlvbkRpcmVjdGlvbl9OYW1lXwAAAAAA
DwAAAAAAAAQEAAAAH19UcmFuc2l0aW9uTGluZVR5cGVzVXNpbmdfTmFtZV8A
AAAADwAAAAAAAAQcAAAAFl9UcmFuc2l0aW9uVmFsaWRfTmFtZV8AAAAAAA8A
AAAAAAAD3AAAABZfVHJhbnNpdGlvblZhbHVlX05hbWVfAAAAAAAPAAAAAAAA
A/AAAAAPZGc0X2RlZl92ZXJzaW9uAAAAAA8AAAAAAAADMAAAAAd5eWRlYnVn
AAAAAAIAAAAAAAACRA==
---843322490-819139725-895075462=:2728--
=======================================================================
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 May 13 09:19:36 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA03210 for info-performer-dist@holodeck.engr.sgi.com; Wed, 13 May 1998 09:03: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 JAA03183 for <info-performer@holodeck.engr.sgi.com>; Wed, 13 May 1998 09:02:32 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA34097
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 13 May 1998 09:02:20 -0700 (PDT)
Received: from acusoft.com (acusoft.acusoft.com [205.187.235.130]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id JAA09395; Wed, 13 May 1998 09:02:06 -0700 (PDT)
	mail_from (miller@acusoft.com)
Received: from marvin by acusoft.com (5.x/SMI-SVR4)
	id AA20739; Wed, 13 May 1998 12:02:02 -0400
Received: by marvin (950413.SGI.8.6.12) id MAA02755; Wed, 13 May 1998 12:02:01 -0400
Date: Wed, 13 May 1998 12:02:01 -0400 (EDT)
From: "Thomas M. Miller" <miller@acusoft.com>
X-Sender: miller@marvin
To: src@rose.engr.sgi.com, dorbie@sgi.com, info-performer@sgi.com
Cc: Jesse Liu <liu@acusoft.com>, Wentao Lyou <lyou@acusoft.com>
Subject: More Info - Re: inf/60.0
In-Reply-To: <Pine.SGI.3.91.980512143842.12972A-100000@distest>
Message-Id: <Pine.SGI.3.91.980513115216.2728A-100000@marvin>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O


I have attached my vfo file.

To view a demonstration (on a single pipe Onyx2) of the effect I am describing:
	1) In ircombine assign the attached vfo to channel 0 and a 1280x1024_60
		vfo to channel 1.
	2) Save the combination to eeprom.
	3) Switch your monitor cable to channel 1 while you stop and start
		graphics ( be careful most monitors don't like the 180Hz
		field sequential signal )
	4) Run a Performer 2.2 perfly ( no DB or model required )
	5) Open stats and observe frame rate.

--TMIV

On Tue, 12 May 1998, Thomas M. Miller wrote:

> 
> I found a correlation between the inf/60.0 and certain video modes.
> 
> My operational video mode is a 1024x768_180 stereo field sequential mode.
> If I change this mode to a 60Hz mode my frame stats go back to reading
> 60/60. Does my 180Hz video mode have adverse effects on the VClock and
> pfClock?  Could this be causing timing problems other than an erroneous 
> frame rate display?
> 
> --TMIV

=======================================================================
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 May 13 10:55:55 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA03692 for info-performer-dist@holodeck.engr.sgi.com; Wed, 13 May 1998 10:37: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 KAA03665 for <info-performer@holodeck.engr.sgi.com>; Wed, 13 May 1998 10:37:27 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA76313
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 13 May 1998 10:37:26 -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 KAA22027
	for <info-performer@sgi.com>; Wed, 13 May 1998 10:37:20 -0700 (PDT)
	mail_from (cano@silicon.cl)
Mtz-Posted-Date: Wed, 13 May 1998 14:36:39 -0700
Received: from ivory.silicon.cl(200.29.40.2) by challenge via smap (3.1)
	id xma020178; Wed, 13 May 98 14:36:37 -0700
Received: from krusty (krusty [200.29.40.72]) by silicon.cl (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA22455; Wed, 13 May 1998 13:37:57 -0400
Received: (from cano@localhost) by krusty (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA02997; Wed, 13 May 1998 13:50:57 -0400
From: "Alejandro Saez" <cano@silicon.cl>
Message-Id: <9805131350.ZM2995@krusty>
Date: Wed, 13 May 1998 13:50:57 -0400
In-Reply-To: Stefano Conconi <conconi@stigma.it>
        "Euler angles" (May 13,  2:55pm)
References: <35599846.794213A9@stigma.it>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Stefano Conconi <conconi@stigma.it>
Subject: Re: Euler angles
Cc: info-performer@sgi.engr.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On May 13,  2:55pm, Stefano Conconi wrote:
> Subject: Euler angles
> Hi,
> Could some one tell me somethinghs about the transformation between
>
> Euler parameters - Euler angles- Yaw Pitch and Roll
>
> for the orientation of an object?
>
> Which algorithms I can use to do this transformation?
>
> Or where can I find some usefull links about all of this kind of
> orientation rappresentation?
> --
> -----------------------------------------------------------------
>  Ing. Stefano Conconi
>                         STIGMA On-Line S.r.l.
>                         PAVIA  - Italy
> -----------------------------------------------------------------
> E-Mail: conconi@stigma.it    Phone:  +39 (0382) 578948-9
> WWW: http://www.stigma.it    Fax:    +39 (0382) 577902
>
>
> =======================================================================
> 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 Stefano Conconi

They are the basically same thing, euler angles is just a way of representing
an object's orientation, and they are basically the angles along the principal
axis (x,y and Z), which is the definition of Pitch, yaw and Roll. Now a lot of
confusion usually arises because of the definition of what is positive X,
positive Y and positive Z, and also what is considered to be a positive
rotation (either left or right hand) and also which positive axis is the
"heading".  This gives A LOT of different ways of representing the same thing.
For example:

	Classical Flight Simulation:

		+X left
		+Y away from observer
		+Z down
		right hand angles
		+X is "move forward"

	Foley,

		+X left
		+Y up
		+Z from screen towards observer
		right hand angles
		+X is forward

	Performer (not sure, but I think)
		+X left
		+Y from screen towards observer
		+Z up
		right hand rule
		etc,

	This is just to show that although each and every one of this systems
use Yaw, Pitch and Roll (that is Euler angles) you would end up with totally
different rotation matrices for the same, say, Yaw angle, this sometimes leads
to some confusion.

	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  Wed May 13 13:11:40 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA19140 for info-performer-dist@holodeck.engr.sgi.com; Wed, 13 May 1998 12:57: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 MAA19113 for <info-performer@holodeck.engr.sgi.com>; Wed, 13 May 1998 12:57:02 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA36259
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 13 May 1998 12:57:01 -0700 (PDT)
Received: from multipass.engr.sgi.com ([198.29.106.105]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id MAA22112
	for <info-performer@sgi.engr.sgi.com>; Wed, 13 May 1998 12:56:59 -0700 (PDT)
	mail_from (dorbie@sgi.com)
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 MAA06022; Wed, 13 May 1998 12:56:56 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <3559FB08.9319FE0C@sgi.com>
Date: Wed, 13 May 1998 12:56:56 -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: Alejandro Saez <cano@silicon.cl>
CC: Stefano Conconi <conconi@stigma.it>, info-performer@fddi-sgi.sgi.com
Subject: Re: Euler angles
References: <35599846.794213A9@stigma.it> <9805131350.ZM2995@krusty>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Alejandro Saez wrote:
> 
> On May 13,  2:55pm, Stefano Conconi wrote:
> > Subject: Euler angles
> > Hi,
> > Could some one tell me somethinghs about the transformation between
> >
> > Euler parameters - Euler angles- Yaw Pitch and Roll
> >
> > for the orientation of an object?
> >
> > Which algorithms I can use to do this transformation?
> >
> > Or where can I find some usefull links about all of this kind of
> > orientation rappresentation?
> > --
> > -----------------------------------------------------------------
> >  Ing. Stefano Conconi
> >                         STIGMA On-Line S.r.l.
> >                         PAVIA  - Italy
> > -----------------------------------------------------------------
> > E-Mail: conconi@stigma.it    Phone:  +39 (0382) 578948-9
> > WWW: http://www.stigma.it    Fax:    +39 (0382) 577902
> >
> >
> > =======================================================================
> > 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 Stefano Conconi
> 
> They are the basically same thing, euler angles is just a way of representing
> an object's orientation, and they are basically the angles along the principal
> axis (x,y and Z), which is the definition of Pitch, yaw and Roll. Now a lot of
> confusion usually arises because of the definition of what is positive X,
> positive Y and positive Z, and also what is considered to be a positive
> rotation (either left or right hand) and also which positive axis is the
> "heading".  This gives A LOT of different ways of representing the same thing.
> For example:
> 
>         Classical Flight Simulation:
> 
>                 +X left
>                 +Y away from observer
>                 +Z down
>                 right hand angles
>                 +X is "move forward"
> 
>         Foley,
> 
>                 +X left
>                 +Y up
>                 +Z from screen towards observer
>                 right hand angles
>                 +X is forward
> 
>         Performer (not sure, but I think)
>                 +X left
>                 +Y from screen towards observer

This is wrong, Y is from observer into screen.

>                 +Z up
>                 right hand rule
>                 etc,
> 
>         This is just to show that although each and every one of this systems
> use Yaw, Pitch and Roll (that is Euler angles) you would end up with totally
> different rotation matrices for the same, say, Yaw angle, this sometimes leads
> to some confusion.
> 
>         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

-- 
"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 May 13 13:11:40 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA18163 for info-performer-dist@holodeck.engr.sgi.com; Wed, 13 May 1998 12:48: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 MAA18136 for <info-performer@holodeck.engr.sgi.com>; Wed, 13 May 1998 12:48:49 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA30875
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 13 May 1998 12:48: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 MAA19234
	for <info-performer@sgi.com>; Wed, 13 May 1998 12:48:40 -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 (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA31022;
	Wed, 13 May 1998 12:48:34 -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 MAA06037; Wed, 13 May 1998 12:48:18 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <3559F901.921D44E9@sgi.com>
Date: Wed, 13 May 1998 12:48:17 -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: Andrew Ng <nga@division.co.uk>
CC: "'kbrussel@media.mit.edu'" <kbrussel@media.mit.edu>,
        Performer Enthusiasts <info-performer@sgi.com>
Subject: Re: Shadow bug
References: <01BD7E5A.1B0041C0@nga.division.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Andrew Ng wrote:
> 
> > We're using the pfLightSource mechanism on an Onyx2 with iR
> > graphics to generate shadows in our application. We have found
> > that with certain camera positions, some garbage geometry appears
> > to be creating a shadow; by moving the camera slightly, the
> > effect goes away.
> 
> I have also been using pfLightSource shadows on our Onyx iR (which has
> patch 1808 installed) and have noticed the anomalies that you describe. The
> only explanation I can think of is that the floor geometry is actually
> shadowing itself in these situations. I had a quick go with different
> values for the shadow displace and scale but couldn't come up with a
> satisfactory set up.

The self shadow theory seems unlikely, particularly since only parts
seem to be occulted and you tried different offsets.

Maybe there is some interaction with pfLayers (stencil or polygon
offset)
or other state information and the shadow rendering?

Or perhaps there's a problem with the framebuffer readback although this
seems unlikely since the problem is reported as view dependent.

Have you tried actually reading back z and checking the depth values in
the image array?

One thing to try is to disable antialiasing and see if the problem
persists, this might point an accusatory finger ad zbuffer compression
on iR.

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 May 13 13:26:08 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA19886 for info-performer-dist@holodeck.engr.sgi.com; Wed, 13 May 1998 13:02: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 NAA19858 for <info-performer@holodeck.engr.sgi.com>; Wed, 13 May 1998 13:02:50 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA37477
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 13 May 1998 13:02:49 -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 NAA24441; Wed, 13 May 1998 13:02:35 -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 QAA28771;
	Wed, 13 May 1998 16:02:12 -0400 (EDT)
Received: (from kbrussel@localhost) by komodo-dragon.media.mit.edu (950413.SGI.8.6.12/8.6.11) id UAA24701; Wed, 13 May 1998 20:02:04 GMT
Date: Wed, 13 May 1998 20:02:04 GMT
Message-Id: <199805132002.UAA24701@komodo-dragon.media.mit.edu>
From: Kenneth B Russell <kbrussel@media.mit.edu>
To: Angus Dorbie <dorbie@sgi.com>
CC: nga@division.co.uk, Performer Enthusiasts <info-performer@sgi.com>
In-reply-to: <3559F901.921D44E9@sgi.com> (message from Angus Dorbie on Wed, 13
	May 1998 12:48:17 -0700)
Subject: Re: Shadow bug
Reply-to: kbrussel@media.mit.edu
Status: O


> The self shadow theory seems unlikely, particularly since only parts
> seem to be occulted and you tried different offsets.
> 
> Maybe there is some interaction with pfLayers (stencil or polygon
> offset)
> or other state information and the shadow rendering?
>
> One thing to try is to disable antialiasing and see if the problem
> persists, this might point an accusatory finger ad zbuffer compression
> on iR.

We don't do anything fancy in our application yet; no stencil
planes, no antialiasing, and no manual use of the polygon offset
extension.

The problem is concisely shown in this example from the Performer
2.2 MR.

If you compile /usr/share/Performer/shadows.c from
/usr/share/Performer/src/pguide/libpf/C with the following
command line:

cc -o shadows shadows.c -lpf -lpfdu -lpfutil -lGL -lGLU -lX11 -limage

(we're using the 7.1 compilers patched up to #2072, on an Onyx2
iR running Irix 6.4), and then run the executable by

shadows stool.flt

(where stool.flt is in /usr/share/Performer/data), then there
will be two "blips" as the shadowed light does its orbit; the
shadow suddenly turns into a big black box for a moment. Those
blips look exactly like what I'm seeing in my application.

We have a support contract; should I be reporting this problem in
some other venue than here?

Thanks,

-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  Wed May 13 13:41:32 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA19967 for info-performer-dist@holodeck.engr.sgi.com; Wed, 13 May 1998 13:13: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 NAA19940 for <info-performer@holodeck.engr.sgi.com>; Wed, 13 May 1998 13:13:10 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA43084
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 13 May 1998 13:13:10 -0700 (PDT)
Received: from sunu450.rz.ruhr-uni-bochum.de (sunu450.rz.ruhr-uni-bochum.de [134.147.222.33]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id NAA29107
	for <info-performer@sgi.com>; Wed, 13 May 1998 13:13:05 -0700 (PDT)
	mail_from (Bert.Grollmann@rz.ruhr-uni-bochum.de)
Message-Id: <199805132013.NAA29107@sgi.sgi.com>
Received: (qmail 29720 invoked from network); 13 May 1998 20:12:59 -0000
Received: from dialppp-1-13.rz.ruhr-uni-bochum.de (HELO pc0001) (134.147.1.13)
  by mailhost.rz.ruhr-uni-bochum.de with SMTP; 13 May 1998 20:12:59 -0000
X-Sender: grollbbo@mailhost.rz.ruhr-uni-bochum.de
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Wed, 13 May 1998 22:13:01 +0200
To: info-performer@sgi.com
From: "B. Grollmann" <Bert.Grollmann@rz.ruhr-uni-bochum.de>
Subject: Perfly demo path
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Status: O

Hi Performers,

can someone explain, how the perfly demo flight work ?!?!
I found the place in cmdline.C where I can set the file path to load,
but where are the path-points are loaded und written into the view.mat ???

Hope, someone can explain this mysterious thing.....

Thanks for your help
   Bert


        It's up to us to virtualise your environment !
        ..............................................
    Bert Grollmann   mailto:Bert.Grollmann@Ruhr-Uni-Bochum.de
		       mailto:Bert.Grollmann@FH-Bochum.de      
 ======================================================================
    RUB - Ruhr University Bochum
    FH  - Polytechnical Institute of Bochum
          Dept. for artificial intelligence, system software 
                and graphic systems
                kiss-lab

    Lennershofstr. 140 
    44801 Bochum 
    Germany 
 ======================================================================
=======================================================================
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 May 13 14:11:21 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA20489 for info-performer-dist@holodeck.engr.sgi.com; Wed, 13 May 1998 13:51: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 NAA20462 for <info-performer@holodeck.engr.sgi.com>; Wed, 13 May 1998 13:51:11 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA61724
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 13 May 1998 13:51:11 -0700 (PDT)
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 NAA16077
	for <info-performer@sgi.com>; Wed, 13 May 1998 13:51:09 -0700 (PDT)
	mail_from (boccara@MIT.EDU)
Received: from MIT.MIT.EDU by MIT.EDU with SMTP
	id AA15516; Wed, 13 May 98 16:51:04 EDT
Received: from VETREC2.MIT.EDU by MIT.MIT.EDU (5.61/4.7) id AA07478; Wed, 13 May 98 16:51:05 EDT
Sender: boccara@MIT.EDU
Message-Id: <355A322F.F46E6F19@mit.edu>
Date: Wed, 13 May 1998 16:52:15 -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: Performer <info-performer@sgi.com>
Subject: *standard* 3D LinMath lib ?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Hi all,

I am looking for a "standard" C/C++/Macros library for 3-Space linear algebra
computations : i.e. matrices (3x3/4x4/row/etc...), vectors, quats, etc.
Something that also works with doubles, and that is independant from Performer
or any 3D commercial library.
As you may guess, I'm trying to free my development from pfLinMath.h...
Please help me to avoid re-inventing the wheel...

Thanks,

Mike

-- 
Michael Boccara     Massachussets Institute of Technology
Visiting Scientist  Research Laboratory of Electronics
boccara@mit.edu     Virtual Environment Technologies for Training
 1-617-253 0005     50 Vassar Street - #36.219 - Cambridge, MA 02139
=======================================================================
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 May 13 14:11:22 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA20456 for info-performer-dist@holodeck.engr.sgi.com; Wed, 13 May 1998 13:50: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 NAA20429 for <info-performer@holodeck.engr.sgi.com>; Wed, 13 May 1998 13:50:06 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA59548
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 13 May 1998 13:50: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 NAA15520
	for <info-performer@sgi.com>; Wed, 13 May 1998 13:50:03 -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 (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA61751;
	Wed, 13 May 1998 13:49:56 -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 NAA06169; Wed, 13 May 1998 13:49:04 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <355A073F.C1CDEB7A@sgi.com>
Date: Wed, 13 May 1998 13:49: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: kbrussel@media.mit.edu
CC: nga@division.co.uk, Performer Enthusiasts <info-performer@sgi.com>
Subject: Re: Shadow bug
References: <199805132002.UAA24701@komodo-dragon.media.mit.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Kenneth B Russell wrote:
> 
> > The self shadow theory seems unlikely, particularly since only parts
> > seem to be occulted and you tried different offsets.
> >
> > Maybe there is some interaction with pfLayers (stencil or polygon
> > offset)
> > or other state information and the shadow rendering?
> >
> > One thing to try is to disable antialiasing and see if the problem
> > persists, this might point an accusatory finger ad zbuffer compression
> > on iR.
> 
> We don't do anything fancy in our application yet; no stencil
> planes, no antialiasing, and no manual use of the polygon offset
> extension.
> 
> The problem is concisely shown in this example from the Performer
> 2.2 MR.
> 
> If you compile /usr/share/Performer/shadows.c from
> /usr/share/Performer/src/pguide/libpf/C with the following
> command line:
> 
> cc -o shadows shadows.c -lpf -lpfdu -lpfutil -lGL -lGLU -lX11 -limage
> 
> (we're using the 7.1 compilers patched up to #2072, on an Onyx2
> iR running Irix 6.4), and then run the executable by
> 
> shadows stool.flt
> 
> (where stool.flt is in /usr/share/Performer/data), then there
> will be two "blips" as the shadowed light does its orbit; the
> shadow suddenly turns into a big black box for a moment. Those
> blips look exactly like what I'm seeing in my application.
> 
> We have a support contract; should I be reporting this problem in
> some other venue than here?

Yes. For call tracking etc you should log a call with your local
customer support.

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 May 13 15:49:55 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA20868 for info-performer-dist@holodeck.engr.sgi.com; Wed, 13 May 1998 15:32: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 PAA20841 for <info-performer@holodeck.engr.sgi.com>; Wed, 13 May 1998 15:32:57 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id PAA01079
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 13 May 1998 15:32:58 -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 PAA26437
	for <info-performer@sgi.com>; Wed, 13 May 1998 15:32:53 -0700 (PDT)
	mail_from (cano@silicon.cl)
Mtz-Posted-Date: Wed, 13 May 1998 19:32:20 -0700
Received: from ivory.silicon.cl(200.29.40.2) by challenge via smap (3.1)
	id xma022862; Wed, 13 May 98 19:32:07 -0700
Received: from krusty (krusty [200.29.40.72]) by silicon.cl (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA05472; Wed, 13 May 1998 18:33:29 -0400
Received: (from cano@localhost) by krusty (950413.SGI.8.6.12/950213.SGI.AUTOCF) id SAA03237; Wed, 13 May 1998 18:46:29 -0400
From: "Alejandro Saez" <cano@silicon.cl>
Message-Id: <9805131846.ZM3235@krusty>
Date: Wed, 13 May 1998 18:46:29 -0400
In-Reply-To: Michael Boccara <boccara@MIT.EDU>
        "*standard* 3D LinMath lib ?" (May 13,  4:52pm)
References: <355A322F.F46E6F19@mit.edu>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Michael Boccara <boccara@MIT.EDU>
Subject: Re: *standard* 3D LinMath lib ?
Cc: info-performer@sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On May 13,  4:52pm, Michael Boccara wrote:
> Subject: *standard* 3D LinMath lib ?
> Hi all,
>
> I am looking for a "standard" C/C++/Macros library for 3-Space linear algebra
> computations : i.e. matrices (3x3/4x4/row/etc...), vectors, quats, etc.
> Something that also works with doubles, and that is independant from
Performer
> or any 3D commercial library.
> As you may guess, I'm trying to free my development from pfLinMath.h...
> Please help me to avoid re-inventing the wheel...
>
> Thanks,
>
> Mike
>
> --
> Michael Boccara     Massachussets Institute of Technology
> Visiting Scientist  Research Laboratory of Electronics
> boccara@mit.edu     Virtual Environment Technologies for Training
>  1-617-253 0005     50 Vassar Street - #36.219 - Cambridge, MA 02139
> =======================================================================
> 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

Mmmmhhh, something else??? Just kidding.. OpenGL does some and is as standard
as it gets (my humble opinion). Any other library, will free you from
performer/OpenGl but it won't be very standard and thus portable, if this isn't
a problem with you, I would recommend the algebra library that comes with one
of the Graphics Gems books (I can't remember which one) The source code for the
first 3 books is available in the web...can't remember where either, but a
search in any decent engine should point you to the source code, it's a C++
library, operator overloaded for 3D and 2D CG.


-- 
------------------------------------------------------------------------
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 May 13 15:49:55 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA20906 for info-performer-dist@holodeck.engr.sgi.com; Wed, 13 May 1998 15:36: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 PAA20879 for <info-performer@holodeck.engr.sgi.com>; Wed, 13 May 1998 15:36:07 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA85961
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 13 May 1998 14:59:50 -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 OAA14573
	for <info-performer@sgi.com>; Wed, 13 May 1998 14:58:34 -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 PAA25315 for <info-performer@sgi.com>; Wed, 13 May 1998 15:09: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 VAA13204 for <@plateau.engr.multigen.com:info-performer@sgi.com>; Wed, 13 May 1998 21:59:53 GMT
Received: (from marcus@localhost) by logan.engr.multigen.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA13998 for info-performer@sgi.com; Wed, 13 May 1998 14:59:52 -0700
From: "Marcus Barnes" <marcus@multigen.com>
Message-Id: <9805131459.ZM13996@logan.engr.multigen.com>
Date: Wed, 13 May 1998 14:59:52 -0700
In-Reply-To: "Laurent Ach" <ach@syseca.fr>
        "flt loader backward compatibility" (May 13,  4:02pm)
References: <9805131602.ZM15105@anna.internet.syseca>
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: flt loader backward compatibility
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On May 13,  4:02pm, Laurent Ach wrote:
>... it would be nice if someone could tell
>me how to run an application built with Performer 2.1 and using the flt
loader,
>in a Performer 2.2 execution environment.

This is referring to the fact that the performer_eoe.compat\* subsystems
released with Performer 2.2 are broken. The short answer is you can't do this
until SGI fixes those compatibility libraries and issues a patch.

>Because the loader can't be found event with the compatibility DSO installed.

This is a different problem. A combination of bugs with (newer) rld and
pfdLoadFile prevent versioned DSOs from linking properly. A workaround for this
is to create a symbolic link to the versioned DSO that you need. For example:

  su
  cd /usr/lib/libpfdb
  ln -s libpfft_ogl.so.3 libpfflt_ogl.so

PS: SGI is in the process of fixing these problems.

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-4103       +
=======================================================================
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 May 14 00:23:25 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id AAA08061 for info-performer-dist@holodeck.engr.sgi.com; Thu, 14 May 1998 00:07: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 AAA08034 for <info-performer@holodeck.engr.sgi.com>; Thu, 14 May 1998 00:07:35 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id AAA67347
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 14 May 1998 00:07:33 -0700 (PDT)
Received: from wgs.estec.esa.nl (hal.wgs.estec.esa.nl [131.176.22.216]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id AAA12934
	for <info-performer@sgi.com>; Thu, 14 May 1998 00:07:31 -0700 (PDT)
	mail_from (simon@wgs.estec.esa.nl)
Received: from deneb by wgs.estec.esa.nl (SMI-8.6/SMI-SVR4)
	id JAA07303; Thu, 14 May 1998 09:06:58 +0200
Sender: simon@wgs.estec.esa.nl
Message-ID: <355A9813.6449@wgs.estec.esa.nl>
Date: Thu, 14 May 1998 09:06:59 +0200
From: Simon Mills <simon@wgs.estec.esa.nl>
Organization: European Space Agency (ESA/ESTEC)
X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4m)
MIME-Version: 1.0
To: "B. Grollmann" <Bert.Grollmann@rz.ruhr-uni-bochum.de>
CC: info-performer@sgi.com
Subject: Re: Perfly demo path
References: <199805132013.NAA29107@sgi.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

B. Grollmann wrote:
> 
> Hi Performers,
> 
> can someone explain, how the perfly demo flight work ?!?!
> I found the place in cmdline.C where I can set the file path to load,
> but where are the path-points are loaded und written into the view.mat ???
> 
> Hope, someone can explain this mysterious thing.....

Just try reading the manual, "man perfly" should tell you all you need
to know.

Regards, Simon

======================================================================
Simon Mills
Modelling & Simulation Section (EMM)
European Space Agency (ESA/ESTEC)
Postbus 299                           e-mail:   simon@wgs.estec.esa.nl
2200AG Noordwijk                      phone:    +31-(0)71-565-3725
The Netherlands                       fax:      +31-(0)71-565-5419
======================================================================
=======================================================================
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 May 14 04:20:23 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id DAA08464 for info-performer-dist@holodeck.engr.sgi.com; Thu, 14 May 1998 03:56: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 DAA08437 for <info-performer@holodeck.engr.sgi.com>; Thu, 14 May 1998 03:56:29 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id DAA20438
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 14 May 1998 03:56:29 -0700 (PDT)
Received: from windows1.ks-t.no (windows1.ks-t.no [193.71.169.107]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id DAA26527
	for <info-performer@sgi.com>; Thu, 14 May 1998 03:55:43 -0700 (PDT)
	mail_from (oyvind.roa@ks-t.no)
Received: from stokke ([193.71.171.81]) by windows1.ks-t.no
          (post.office MTA v1.9.1 ID# 0-11124) with SMTP id AAA345
          for <info-performer@sgi.com>; Thu, 14 May 1998 12:55:03 +0200
Sender: oyvindr@ks-t.no
Message-ID: <355ACD87.41C6@ks-t.no>
Date: Thu, 14 May 1998 12:55:03 +0200
From: Oyvind Roa <oyvind.roa@ks-t.no>
Organization: ks-t
X-Mailer: Mozilla 3.01SGoldC-SGI (X11; I; IRIX 6.3 IP32)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: Possible memory leak in Performer2.2 . 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

I am currently working on a project where we have
a large geospecific database which has been tiled.
The application should be able to run for at least
8 hours, where the user might contiguously fly
around in the terrain. This might lead to several
hundred tiles being loaded and removed during a
session in the DBase process.

My problem is that the application slowly consumes more
and more memory, until the shared arena goes full.
I have been able to isolate the problem down to a small
test program (attached), actually using "pftown.pfb"
to simulate my real terrain tiles. The symthoms are the
same for my real tiles and "pftown.pfb".

I expect that there is something which is not allocated
shared in the loader (using the standard .pfb loader) which
is not freed when I remove the tile, or is it due to memory
fragmentation of the arena.

Does some of you know immediately what my problem is, or
alternatively how should I proceed to find out where the
memory goes ?


Environment :

Workstation : 8 cpu Onys2 InfiniteReality, 2 pipes
OpSys       : IRIX6.4
Software    : ProDev7.2
              Performer2.2


Test program :
-----------------------

#include <stdlib.h>
#include <strings.h>

#include <Performer/pf.h>
#include <Performer/pfdu.h>
#include <Performer/pfutil.h>
#include <stdio.h>
#include <math.h>


/* Function prototypes */

void updateDBase(void *data);
void windowSetup(char *title);
void channelSetup(void);
void handleEvents(void);


/* Type declarations */

typedef struct {
    pfGroup     *group;
} SharedData;


/* Global variables */

SharedData      *shared  = NULL ;
pfChannel       *chan    = NULL  ;
pfScene         *scene   = NULL  ;
int             exitFlag = 0;


int main(int argc, char *argv[])
{

  void            *arena ;
  pfLightSource   *light;

  /* Set the shared arena size to approx. 100MByte
     to get an overflow earlier than with the default
     one. The program runs out of shared memory
     after approx. 90 loads */

  pfSharedArenaSize(100000000L) ;
  pfInit() ;
  pfuInitUtil() ;

  arena = pfGetSharedArena();
  shared = (SharedData *)pfMalloc(sizeof(SharedData), arena);

  /* Configure the database paging to run in an async. subprocess */
  pfMultiprocess(PFMP_APP_CULL_DRAW | PFMP_FORK_DBASE);

  pfdInitConverter("pfb") ;

  /* Forks CULL and DRAW and DBase */
  pfConfig() ;

  /* Create a X-window, and associate it with pipe 0 */
  windowSetup(argv[0]);

  /* Creat a scene */
  scene = pfNewScene() ;

  /* Add a light source to the scene */
  light = pfNewLSource();
  pfAddChild(scene, light);

  /* Hook all the tiles in under a top group node */
  shared->group = pfNewGroup();
  pfAddChild(scene, shared->group);

  /* Create an setup a channel */
  channelSetup();

  /* Register DBase callback */
  pfDBaseFunc(updateDBase);

  /* Set framerate to 30Hz */
  pfFrameRate(30.0f) ;
  pfPhase(PFPHASE_LIMIT) ;

  while( !exitFlag) {
     pfSync() ;
     pfFrame() ;
  }

  pfuExitUtil() ;
  pfExit() ;

  exit(0) ;
}

/* Max number generated by rand()  (2^16 - 1) */
#define MAX_RAND 32767.0

/* Max number of tiles simultanously loaded   */
#define MAX_TILES 9


/* updateDBase() is called async. by pfFrame()
in the forked DBase process. */

void updateDBase(void *data)
{
  extern SharedData   *shared;

  static pfNode       *Tiles[MAX_TILES] ;
  static pfBuffer     *buf = NULL;
  static int          nLoads = 0 ;
  static int          nLoaded= 0 ;
  int num ;

  if (!buf) {
    /* Clear the Tiles array */
    bzero(Tiles, sizeof(pfNode *)*MAX_TILES) ;

    /* Create and select a new pfBuffer to work with. */
    buf = pfNewBuffer();
    pfSelectBuffer(buf);

    /* Set the PFFILEPATH */
    pfFilePath(".:./pftexture");
  }

  /* Generate a random number from 0 to MAX_TILES-1  */
  num = (int)(((float)rand() / MAX_RAND) *
             ((float)MAX_TILES - 0.00001))  ;

  /* Check if the randomly selected tile is already loaded */
  if (Tiles[num]) {

    /* Remove the scenegraph subtree representing this tile */

    pfBufferRemoveChild(shared->group, Tiles[num]);
    pfAsyncDelete(Tiles[num]);
    Tiles[num] = NULL ;
    printf("Removed tile %d\n", num) ;

    /* Decrement how many tiles currently loaded. */
    nLoaded-- ;

  } else {

    /* Load a new instance of the town, and put it into the
       scenegraph under the selected tile number.  */

    Tiles[num] = pfdLoadFile("town.pfb") ;
    pfBufferAddChild(shared->group, Tiles[num]);

    printf("Loaded tile %d\n", num) ;

    /* Increment number of loads done. */
    nLoads++ ;
    /* Increment how many tiles currently loaded. */
    nLoaded++ ;
  }

  printf("Number of loads ==> %d\n", nLoads) ;
  printf("Number of tiles loaded ==> %d\n", nLoaded) ;

  /* Merge the newly loaded tile (if any) into the scene. */
  pfMergeBuffer();

  /* Carry out the asynchronous deletion requests if any pending */
  pfDBase();

}

void windowSetup(char *title)
{
  pfPipe          *pipe;
  pfPipeWindow    *win;

  pipe = pfGetPipe(0);
  win = pfNewPWin(pipe);
  pfPWinName(win, title);

  pfPWinSize(win, 1000, 1000);

  pfPWinType(win, PFPWIN_TYPE_X) ;
  pfuInitInput(win, PFUINPUT_X) ;

  pfOpenPWin(win);
}

void channelSetup()
{
  extern pfChannel *chan ;
  pfPipe          *pipe;
  pfCoord         view;

  pipe = pfGetPipe(0);
  chan = pfNewChan(pipe);
  pfChanScene(chan, scene);

  pfChanNearFar(chan, 1.0f, 5000.0f) ;
  pfChanFOV(chan, 60.0f, -1.0f) ;

  /* Position the channel where it is known to
     see part of the loaded database */
  pfSetVec3(view.hpr, 0.0f, -20.0f, 0.0f);
  pfSetVec3(view.xyz, 3000.0f, 3000.0f, 50.0f);
  pfChanView(chan, view.xyz, view.hpr) ;

}


-----------------------
 
Oyvind Roa
Senior Software Engineer

Kongsberg Defence & Aerospace A/S Phone:  (+47) 32723253
P.O. Box 1003                     Fax:    (+47) 32286902
N-3601 Kongsberg                  Email:  oyvind.roa@kongsberg.com
Norway
=======================================================================
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 May 14 07:22:28 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA08792 for info-performer-dist@holodeck.engr.sgi.com; Thu, 14 May 1998 07:00: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 HAA08765 for <info-performer@holodeck.engr.sgi.com>; Thu, 14 May 1998 07:00:39 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA60157
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 14 May 1998 07:00:39 -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 HAA08458; Thu, 14 May 1998 07:00:33 -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 JAA20281; Thu, 14 May 1998 09:00:32 -0500 (CDT)
Date: Thu, 14 May 1998 09:00:09 -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>
cc: Sharon Clay <src@sgi.com>
Subject: Flat Triangle Fan bug in Perf 2.2MR??
Message-ID: <Pine.SGI.3.96.980514084625.29024A-100000@sutcliffe.bgm.link.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O


I think I just found a bug in Perf 2.2 MR (IRIX 6.2, ONYX iR).

We just added support for PFGS_TRIFANS and PFGS_FLAT_TRIFANS into our
package.

We find that the pfGSetIsectMask function crashes when we pass
it a pfGeoSet containing a PFGS_FLAT_TRIFANS primitive. PFGS_TRIFANS
seem to work OK.

The pfGSetIsectMask call is being made inside either APP or DBASE -
the effect is the same, Performer says:

FATAL pfMalloc() Unable to allocate 383526720 bytes from arena 0x18380000.

...which is odd since this is only a 20 vertex tFan. :-)

DBX says...

...

   2 ::pfNotify(0x1a2f03f0, 0xa, 0x7ffc6ca0, 0x0, 0x0, 0x41100000, 0x0, 0x0)
["/build/perfbuild/perftot0/perf/lib/libpr/notify.C":291, 0x5d79fa2c]
   3 pfGeoSet::pr_mallCache(int)(0x1a2f03f0, 0x40f3d6f8, 0x7ffc6ca0, 0x0, 0x9, 0x1, 0x0, 0xa) ["/build/perfbuild/perftot0/perf/lib/libpr/pfGeoSet.C":2612, 0x5d715c40]
   4 pfGeoSet::pr_computeCache(void)(0x1a2f03f0, 0xa, 0x7ffc6ca0, 0x0, 0x0, 0x0, 0x0, 0xa)
["/build/perfbuild/perftot0/perf/lib/libpr/pfGeoSet.C":2912, 0x5d7153b4]
   5 pfGeoSet::setIsectMask(unsigned int,int,int)(0x1a2f03f0, 0x0, 0x80, 0xffffffff, 0x9,
0x1, 0x0, 0xa) ["/build/perfbuild/perftot0/perf/lib/libpr/pfGeoSet.C":1741, 0x5d71356c]
   6 ::pfGSetIsectMask(0x1687, 0xa, 0x7ffc6ca0, 0x0, 0x9, 0x1, 0x0, 0xa) 
["/build/perfbuild/perftot0/perf/lib/libpr/cGeoSet.C":459, 0x5d7afdc4]
   7 Loader_Instance::parse_packet(int,int,char*)(this = 0x7ffc9988, opcode = 10, length = 8, buf = 0x7ffc88e8 = "") ["/usr/squeaky2/common/src/loader/loadprf.cxx":867, 0x10114564]

...

The source code says:

  pfAddGSet ( geode, gset ) ;
  pfGSetIsectMask ( gset, PFTRAV_SELF, PFTRAV_IS_CACHE, 0xffffffff ) ;

Since our code to load flat tristrips (which work OK) is essentially identical
to that to load flat trifans, it looks like this is a pfBug.

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 May 14 07:56:15 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA08972 for info-performer-dist@holodeck.engr.sgi.com; Thu, 14 May 1998 07:37: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 HAA08945 for <info-performer@holodeck.engr.sgi.com>; Thu, 14 May 1998 07:37:49 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA72930
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 14 May 1998 07:37:48 -0700 (PDT)
Received: from acusoft.com (acusoft.acusoft.com [205.187.235.130]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id HAA20846
	for <info-performer@sgi.com>; Thu, 14 May 1998 07:37:46 -0700 (PDT)
	mail_from (miller@acusoft.com)
Received: from marvin by acusoft.com (5.x/SMI-SVR4)
	id AA23642; Thu, 14 May 1998 10:37:45 -0400
Received: by marvin (950413.SGI.8.6.12) id KAA13821; Thu, 14 May 1998 10:37:35 -0400
Date: Thu, 14 May 1998 10:37:35 -0400 (EDT)
From: "Thomas M. Miller" <miller@acusoft.com>
X-Sender: miller@marvin
To: Oyvind Roa <oyvind.roa@ks-t.no>
Cc: info-performer@sgi.com
Subject: Re: Possible memory leak in Performer2.2 . 
In-Reply-To: <355ACD87.41C6@ks-t.no>
Message-Id: <Pine.SGI.3.91.980514103130.13786B-100000@marvin>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O


We had a similar problem here at Acusoft. We would fly around and page
tiles in and out and it didn't take long for the pfSharedArena to run out of
space.  When a tile was unloaded the shared arena would mark space free
but not enough. I didn't work on it but Acusoft's conclusion was that
pfAsyncDelete and pfDelete have problems in pfDBase. So we now pfAsyncDelete
our tiles in the App. The problem seems to be reduced if not entirely gone.


--TMIV

On Thu, 14 May 1998, Oyvind Roa wrote:

> My problem is that the application slowly consumes more
> and more memory, until the shared arena goes full.
> I have been able to isolate the problem down to a small
> test program (attached), actually using "pftown.pfb"
> to simulate my real terrain tiles. The symthoms are the
> same for my real tiles and "pftown.pfb".
=======================================================================
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 May 14 09:21:57 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA09289 for info-performer-dist@holodeck.engr.sgi.com; Thu, 14 May 1998 09:04: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 JAA09262 for <info-performer@holodeck.engr.sgi.com>; Thu, 14 May 1998 09:04:23 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA92420
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 14 May 1998 09:04:21 -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 JAA25804
	for <info-performer@sgi.com>; Thu, 14 May 1998 09:04: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 LAA26605; Thu, 14 May 1998 11:03:57 -0500 (CDT)
Date: Thu, 14 May 1998 11:03:34 -0500 (CDT)
From: Steve Baker <sbaker@link.com>
X-Sender: steve@sutcliffe.bgm.link.com
Reply-To: Steve Baker <sbaker@link.com>
To: "Thomas M. Miller" <miller@acusoft.com>
cc: Oyvind Roa <oyvind.roa@ks-t.no>, info-performer@sgi.com
Subject: Re: Possible memory leak in Performer2.2 . 
In-Reply-To: <Pine.SGI.3.91.980514103130.13786B-100000@marvin>
Message-ID: <Pine.SGI.3.96.980514105447.7858B-100000@sutcliffe.bgm.link.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

On Thu, 14 May 1998, Thomas M. Miller wrote:

> We had a similar problem here at Acusoft. We would fly around and page
> tiles in and out and it didn't take long for the pfSharedArena to run out of
> space.  When a tile was unloaded the shared arena would mark space free
> but not enough. I didn't work on it but Acusoft's conclusion was that
> pfAsyncDelete and pfDelete have problems in pfDBase. So we now pfAsyncDelete
> our tiles in the App. The problem seems to be reduced if not entirely gone.
 
There was a known bug in Perf2.0 that caused that - there is a patch out
to fix it.

AFAIK, there is no problem in Perf2.2 - my application doesn't seem
to leak any memory at all - despite doing *LOTS* of paging.

On the otherhand, I'm not using any of the standard Performer loaders
(I have my own file format) - so it's possible that one or more of
the standard loaders leaks memory.

BTW: pfAsyncDelete is intended to be called in APP,
although the actual deletion happens in DBASE. You should be able to use
pfDelete in APP - but it takes time to execute on complex terrain tiles,
so doing deletion asynchronously in DBASE is obviously desirable.

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 May 14 13:52:39 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA09781 for info-performer-dist@holodeck.engr.sgi.com; Thu, 14 May 1998 13:44: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 NAA09754 for <info-performer@holodeck.engr.sgi.com>; Thu, 14 May 1998 13:44:02 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA75798
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 14 May 1998 13:44:03 -0700 (PDT)
Received: from scully.mugu.navy.mil ([143.113.1.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id NAA25644
	for <info-performer@sgi.com>; Thu, 14 May 1998 13:44:01 -0700 (PDT)
	mail_from (ofriels1@qmsmtpgw.mugu.navy.mil)
Received: by scully.mugu.navy.mil; id QAA12764; Thu, 14 May 1998 16:43:58 -0400 (EDT)
Received: from tuvok.mugu.navy.mil(143.113.247.22) by scully.mugu.navy.mil via smap (4.1)
	id xma012735; Thu, 14 May 98 13:43:32 -0700
Received: from qmsmtpgw.mugu.navy.mil by tuvok.mugu.navy.mil (4.1/SMI-4.1)
	id AA17762; Thu, 14 May 98 13:41:23 PDT
Message-Id: <n1316969202.21355@qmsmtpgw.mugu.navy.mil>
Date: 14 May 1998 13:11:32 -0100
From: "SCOTT OFRIEL" <ofriels1@qmsmtpgw.mugu.navy.mil>
Subject: Textured Objects
To: info-performer@sgi.com
X-Mailer: Mail*Link SMTP-QM 4.1.0
Status: O

Hello All:

We have a Performer 2.0 application running on High Impact 6.2 and Octane 6.4
that loads in aircraft , missiles and the like.  We recently decided to load
in textured aircraft.  When we use the pfdLoadFile on the textured "flt" file
the following error occurs:
1178: scen: rld: Fatal Error: attemped access to unresolvable symbol in
/usr/lib/libpf_ogl.so: iopen

 I went back from n32 mips3 to o32 mips2 and that did not change anything.

What do I need to do to display a textured object.

Thank you, Scott O'Friel


=======================================================================
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 May 14 14:13:48 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA09854 for info-performer-dist@holodeck.engr.sgi.com; Thu, 14 May 1998 14:00: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 OAA09827 for <info-performer@holodeck.engr.sgi.com>; Thu, 14 May 1998 14:00:36 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA84554
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 14 May 1998 14:00:35 -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 OAA02882
	for <info-performer@sgi.com>; Thu, 14 May 1998 14:00:33 -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 (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA75454;
	Thu, 14 May 1998 14:00:33 -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 OAA07798; Thu, 14 May 1998 14:00:32 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <355B5B70.1C06915B@sgi.com>
Date: Thu, 14 May 1998 14:00:32 -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: SCOTT OFRIEL <ofriels1@qmsmtpgw.mugu.navy.mil>
CC: info-performer@sgi.com
Subject: Re: Textured Objects
References: <n1316969202.21355@qmsmtpgw.mugu.navy.mil>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

SCOTT OFRIEL wrote:
> 
> Hello All:
> 
> We have a Performer 2.0 application running on High Impact 6.2 and Octane 6.4
> that loads in aircraft , missiles and the like.  We recently decided to load
> in textured aircraft.  When we use the pfdLoadFile on the textured "flt" file
> the following error occurs:
> 1178: scen: rld: Fatal Error: attemped access to unresolvable symbol in
> /usr/lib/libpf_ogl.so: iopen
> 
>  I went back from n32 mips3 to o32 mips2 and that did not change anything.
> 
> What do I need to do to display a textured object.
> 
> Thank you, Scott O'Friel
> 
> =======================================================================
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com


Did you link with -limage ?

libpf_ogl.so is calling iopen and you haven't linked to a library
with that function implemented, the options you have (for loaders
to work) prevent the usual fatal errors at compile time.

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 May 14 14:13:47 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA09917 for info-performer-dist@holodeck.engr.sgi.com; Thu, 14 May 1998 14:09: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 OAA09890 for <info-performer@holodeck.engr.sgi.com>; Thu, 14 May 1998 14:09:08 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA88764
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 14 May 1998 14:09:07 -0700 (PDT)
Received: from fltsim.stl.mo.boeing.com ([130.38.220.82]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id OAA06774
	for <info-performer@sgi.com>; Thu, 14 May 1998 14:09:05 -0700 (PDT)
	mail_from (m200562@fltsim.stl.mo.boeing.com)
Received: from fltsim.stl.mo.boeing.com (localhost [127.0.0.1]) by fltsim.stl.mo.boeing.com (8.7.6/8.7.3) with SMTP id QAA22405; Thu, 14 May 1998 16:06:27 -0500 (CDT)
Sender: m200562@fltsim.stl.mo.boeing.com
Message-ID: <355B5CD2.41C6@fltsim.stl.mo.boeing.com>
Date: Thu, 14 May 1998 16:06:26 -0500
From: Tom Jolley <m200562@fltsim.stl.mo.boeing.com>
X-Mailer: Mozilla 3.04C-SGI (X11; I; IRIX 5.3 IP22)
MIME-Version: 1.0
To: Steve Baker <sbaker@link.com>
CC: info-performer@sgi.com
Subject: Re: Possible memory leak in Performer2.2 .
References: <Pine.SGI.3.96.980514105447.7858B-100000@sutcliffe.bgm.link.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Steve Baker wrote:
> 
> 
> BTW: pfAsyncDelete is intended to be called in APP,
> although the actual deletion happens in DBASE. You should be able to use
> pfDelete in APP - but it takes time to execute on complex terrain tiles,
> so doing deletion asynchronously in DBASE is obviously desirable.
> 


The man page for pfAsyncDelete says:

     pfAsyncDelete may be called from any process ...

I use pfAsyncDelete in the DBASE process without any problems.

-- 
Tom Jolley
jolley@fltsim.stl.mo.boeing.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 May 14 14:28:40 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA09958 for info-performer-dist@holodeck.engr.sgi.com; Thu, 14 May 1998 14:12: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 OAA09931 for <info-performer@holodeck.engr.sgi.com>; Thu, 14 May 1998 14:12:16 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA91610
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 14 May 1998 14:12:15 -0700 (PDT)
Received: from fltsim.stl.mo.boeing.com ([130.38.220.82]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id OAA07878
	for <info-performer@sgi.com>; Thu, 14 May 1998 14:11:51 -0700 (PDT)
	mail_from (m200562@fltsim.stl.mo.boeing.com)
Received: from fltsim.stl.mo.boeing.com (localhost [127.0.0.1]) by fltsim.stl.mo.boeing.com (8.7.6/8.7.3) with SMTP id QAA22439 for <info-performer@sgi.com>; Thu, 14 May 1998 16:11:48 -0500 (CDT)
Sender: m200562@fltsim.stl.mo.boeing.com
Message-ID: <355B5CD2.41C6@fltsim.stl.mo.boeing.com>
Date: Thu, 14 May 1998 16:11:47 -0500
From: Tom Jolley <m200562@fltsim.stl.mo.boeing.com>
X-Mailer: Mozilla 3.04C-SGI (X11; I; IRIX 5.3 IP22)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: Re: Possible memory leak in Performer2.2 .
References: <Pine.SGI.3.96.980514105447.7858B-100000@sutcliffe.bgm.link.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Steve Baker wrote:
> 
> 
> BTW: pfAsyncDelete is intended to be called in APP,
> although the actual deletion happens in DBASE. You should be able to use
> pfDelete in APP - but it takes time to execute on complex terrain tiles,
> so doing deletion asynchronously in DBASE is obviously desirable.
> 


The man page for pfAsyncDelete says:

     pfAsyncDelete may be called from any process ...

I use pfAsyncDelete in the DBASE process without any problems.

-- 
Tom Jolley
jolley@fltsim.stl.mo.boeing.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 May 14 14:28:40 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA10037 for info-performer-dist@holodeck.engr.sgi.com; Thu, 14 May 1998 14:17: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 OAA10010 for <info-performer@holodeck.engr.sgi.com>; Thu, 14 May 1998 14:17:47 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA93659
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 14 May 1998 14:17:46 -0700 (PDT)
Received: from fltsim.stl.mo.boeing.com ([130.38.220.82]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id OAA10329
	for <info-performer@sgi.com>; Thu, 14 May 1998 14:17:39 -0700 (PDT)
	mail_from (m200562@fltsim.stl.mo.boeing.com)
Received: from fltsim.stl.mo.boeing.com (localhost [127.0.0.1]) by fltsim.stl.mo.boeing.com (8.7.6/8.7.3) with SMTP id QAA22472 for <info-performer@sgi.com>; Thu, 14 May 1998 16:14:46 -0500 (CDT)
Sender: m200562@fltsim.stl.mo.boeing.com
Message-ID: <355B5EC5.167E@fltsim.stl.mo.boeing.com>
Date: Thu, 14 May 1998 16:14:45 -0500
From: Tom Jolley <m200562@fltsim.stl.mo.boeing.com>
X-Mailer: Mozilla 3.04C-SGI (X11; I; IRIX 5.3 IP22)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: Re: Possible memory leak in Performer2.2 .
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Steve Baker wrote:
> 
> 
> BTW: pfAsyncDelete is intended to be called in APP,
> although the actual deletion happens in DBASE. You should be able to use
> pfDelete in APP - but it takes time to execute on complex terrain tiles,
> so doing deletion asynchronously in DBASE is obviously desirable.
> 


The man page for pfAsyncDelete says:

     pfAsyncDelete may be called from any process ...

I use pfAsyncDelete in the DBASE process without any problems.

-- 
Tom Jolley
jolley@fltsim.stl.mo.boeing.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 May 14 14:59:01 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA10396 for info-performer-dist@holodeck.engr.sgi.com; Thu, 14 May 1998 14:44: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 OAA10369 for <info-performer@holodeck.engr.sgi.com>; Thu, 14 May 1998 14:43:56 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA08557
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 14 May 1998 14:43:56 -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 OAA22569
	for <info-performer@sgi.com>; Thu, 14 May 1998 14:43:54 -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 QAA11566; Thu, 14 May 1998 16:43:18 -0500 (CDT)
Date: Thu, 14 May 1998 16:42:56 -0500 (CDT)
From: Steve Baker <sbaker@link.com>
X-Sender: steve@sutcliffe.bgm.link.com
Reply-To: Steve Baker <sbaker@link.com>
To: Tom Jolley <m200562@fltsim.stl.mo.boeing.com>
cc: info-performer@sgi.com
Subject: Re: Possible memory leak in Performer2.2 .
In-Reply-To: <355B5CD2.41C6@fltsim.stl.mo.boeing.com>
Message-ID: <Pine.SGI.3.96.980514163908.19626C-100000@sutcliffe.bgm.link.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

On Thu, 14 May 1998, Tom Jolley wrote:

> Steve Baker wrote:
> > 
> > 
> > BTW: pfAsyncDelete is intended to be called in APP,
> > although the actual deletion happens in DBASE. You should be able to use
> > pfDelete in APP - but it takes time to execute on complex terrain tiles,
> > so doing deletion asynchronously in DBASE is obviously desirable.
> 
> The man page for pfAsyncDelete says:
> 
>      pfAsyncDelete may be called from any process ...
> 
> I use pfAsyncDelete in the DBASE process without any problems.

Oh, yes - I'm sure you do - but if you are doing it in the
asyncronous DBASE process then you might just as well use
pfDelete. The whole point of pfAsyncDelete is that when run
from APP, it takes very little time - and automagically
schedules the S-L-O-W delete to happen sometime later in DBASE.
If you are already running in DBASE then you might as well call
pfDelete and save all the book-keeping overhead inside Performer.

Anyway, I'm sure that what you are doing *should* be OK.

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 May 14 15:20:29 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA10713 for info-performer-dist@holodeck.engr.sgi.com; Thu, 14 May 1998 15:03: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 PAA10686 for <info-performer@holodeck.engr.sgi.com>; Thu, 14 May 1998 15:03:21 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id PAA17904
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 14 May 1998 15:03:20 -0700 (PDT)
Received: from scully.mugu.navy.mil ([143.113.1.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id PAA01226
	for <info-performer@sgi.com>; Thu, 14 May 1998 15:03:18 -0700 (PDT)
	mail_from (ofriels1@qmsmtpgw.mugu.navy.mil)
Received: by scully.mugu.navy.mil; id SAA15740; Thu, 14 May 1998 18:03:20 -0400 (EDT)
Received: from tuvok.mugu.navy.mil(143.113.247.22) by scully.mugu.navy.mil via smap (4.1)
	id xma015718; Thu, 14 May 98 15:03:10 -0700
Received: from qmsmtpgw.mugu.navy.mil by tuvok.mugu.navy.mil (4.1/SMI-4.1)
	id AA18980; Thu, 14 May 98 15:01:05 PDT
Message-Id: <n1316964424.11017@qmsmtpgw.mugu.navy.mil>
Date: 14 May 1998 15:01:38 -0100
From: "SCOTT OFRIEL" <ofriels1@qmsmtpgw.mugu.navy.mil>
Subject: Tex. Obj OK/ Purple tex. now
To: info-performer@sgi.com
X-Mailer: Mail*Link SMTP-QM 4.1.0
Status: O

Thanks to all for the immediate help.  Linking using -limage did  the trick.

By the way, one of our Octane systems displays purple-ish textures.  The other
Octane is fine.  What do you think is the problem?  I saw an email about TRAM.
 Can this board be re-seated possibly?

Thanks again,
Scott O'Friel


=======================================================================
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 May 15 04:43:29 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id EAA11832 for info-performer-dist@holodeck.engr.sgi.com; Fri, 15 May 1998 04:22: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 EAA11805 for <info-performer@holodeck.engr.sgi.com>; Fri, 15 May 1998 04:21:59 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id EAA28245
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 15 May 1998 04:21:59 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from mail1.netcologne.de (mail1.netcologne.de [194.8.194.104]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id EAA10980
	for <info-performer@sgi.com>; Fri, 15 May 1998 04:21:56 -0700 (PDT)
	mail_from (rpolster@blue-space.de)
Received: from blue-space.de (max2-1.netcologne.de [194.8.195.1])
	by mail1.netcologne.de (8.8.8/8.8.8) with ESMTP id NAA22227
	for <info-performer@sgi.com>; Fri, 15 May 1998 13:22:50 +0200 (MET DST)
X-Ncc-Regid: de.netcologne
Message-ID: <355C2585.E706E161@blue-space.de>
Date: Fri, 15 May 1998 13:22:45 +0200
From: ruediger polster <rpolster@blue-space.de>
X-Mailer: Mozilla 4.05 [en] (WinNT; I)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: accurate Joystick HArdware needed
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 EAA28291
Status: O

Dear Performer starters, wizards and gurus

One question  what have happens 1000 times last Yaer in the mailing list
but I can=B4t find an Answer in
the monthly archives.

I need a Joystick as an Interface for Perfomer2.2 running IRIX 6.2 , 6.3
and 6.4

can anybody send me some good addresses.

thank you in Advance



ruediger polster

Blue Space Media GmbH
Hans-B=F6ckler Str. 163
50354 H=FCrth-Germany
mail: rpolster@blue-space.de
http://www.blue-space.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 May 15 07:28:31 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA12081 for info-performer-dist@holodeck.engr.sgi.com; Fri, 15 May 1998 07:04: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 HAA12054 for <info-performer@holodeck.engr.sgi.com>; Fri, 15 May 1998 07:04:33 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA66952
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 15 May 1998 07:04:34 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from sewekr95.aa.wpafb.af.mil (sewekr95.aa.wpafb.af.mil [134.131.18.216]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id HAA19086
	for <info-performer@sgi.com>; Fri, 15 May 1998 07:04:32 -0700 (PDT)
	mail_from (sewell@siscom.net)
Received: from siscom.net (sewell@localhost [127.0.0.1])
	by sewekr95.aa.wpafb.af.mil (8.8.5/8.8.5) with ESMTP id KAA09154
	for <info-performer@sgi.com>; Fri, 15 May 1998 10:04:43 -0400
Sender: sewell@sewekr95.aa.wpafb.af.mil
Message-ID: <355C4B7A.7F74F31A@siscom.net>
Date: Fri, 15 May 1998 10:04:43 -0400
From: Kenneth Sewell <sewell@siscom.net>
Reply-To: sewell@siscom.net
Organization: Defense Research Associates
X-Mailer: Mozilla 4.03 [en] (X11; I; Linux 2.1.57 i586)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: Problems with Z-buffer.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O



    I have been working on a flight sim that loads in several
rectangular patches of terrain.  The problem is that the z-buffer
works correctly for the elements of each patch individually but
not between the elements of two different patches.  I apologize
if I'm not being very clear, I'll give an example.  If I have two
patches A and B (each of them made up of a few thousand
polygons) with A being closer to the viewer than B.  All of
the polygons in A have been rendered properly with respect
to each other, all of the polygons of B have been rendered
properly with respect to each other.  However parts of B
that should be hidden behind A, are drawn as though they
are nearer.  This only happens to part of B, the rest of it is
behind A, like it should be.  I am loading all of the patches
at the same time and they are all children of one DCS node.
I would appreciate any help you can offer.  Thanks.

                        Ken
                        Sewell@siscom.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  Fri May 15 08:03:38 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA12309 for info-performer-dist@holodeck.engr.sgi.com; Fri, 15 May 1998 07:36: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 HAA12282 for <info-performer@holodeck.engr.sgi.com>; Fri, 15 May 1998 07:36:37 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA73990
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 15 May 1998 07:36:37 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from windows1.ks-t.no (windows1.ks-t.no [193.71.169.107]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id HAA00729
	for <info-performer@sgi.com>; Fri, 15 May 1998 07:36:25 -0700 (PDT)
	mail_from (oyvind.roa@ks-t.no)
Received: from stokke ([193.71.171.81]) by windows1.ks-t.no
          (post.office MTA v1.9.1 ID# 0-11124) with SMTP id AAA344;
          Fri, 15 May 1998 16:35:58 +0200
Sender: oyvindr@ks-t.no
Message-ID: <355C52CF.2781@ks-t.no>
Date: Fri, 15 May 1998 16:35:59 +0200
From: Oyvind Roa <oyvind.roa@ks-t.no>
Organization: ks-t
X-Mailer: Mozilla 3.01SGoldC-SGI (X11; I; IRIX 6.3 IP32)
MIME-Version: 1.0
To: info-performer@sgi.com
CC: Robert C Subr <subrrc@wl.wpafb.af.mil>
Subject: Re: Possible memory leak in Performer2.2 .
References: <980514130549.624@wlp1.wl.wpafb.af.mil.0>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Robert C Subr wrote:
> 
> I had a similar problem with software I wrote to tile a large area data base.
> It turned out to be memory fragmentation.  You can look at the arena use by
> using the amallinfo() from the amalloc functions.  This might help you
> determine if it is a memory fragmentation problem or a leak in your code.  Hope
> this helps some.  Good Luck.
> 
> Rob


Thanks a lot Robert for pointing me in the right direction.
I have tried amallinfo() in my application, and found that
I do get huge amounts of "Free ordinary blocks" after a
while. I have plaid around with amallopt(), and have now
reduced the "memory leakage" down to a fraction, however it
is not completely gone. What made the biggest difference was
the option :
	amallopt(M_FREEHD, 1, pfGetSharedArena()) ;
but I also increased the number of free blocks amalloc()
scans before it grabs a new one, done with the function:
	amallopt(M_MXCHK, 1000L, pfGetSharedArena()) ;
Increasing the number of free blocks scanned has some
performance penalty, so it should probably be kept as low as
possible without "eating" to much memory.

Does anyone know how I can reduse this problem the most, in
addition to or instead of tuning with amallopt(). A typical
report from amallinfo()looks like this :

amallinfo : Arena size             : 133480432
amallinfo : Ordinary blocks        : 406292
amallinfo : Small blocks           : 460200
amallinfo : Holding block headers  : 147264
amallinfo : Holding blocks         : 4602
amallinfo : Small blocks in use    : 6460256
amallinfo : Free small blocks      : 1461344
amallinfo : Ordinary blocks in use : 80166016
amallinfo : Free ordinary blocks   : 45245552
amallinfo : Space penalty if keep  : 0


Oyvind


-- 
Oyvind Roa
Kongsberg Defence & Aerospace A/S Phone:  (+47) 32723253
P.O. Box 1003                     Fax:    (+47) 32286902
N-3601 Kongsberg                  Email:  oyvind.roa@kongsberg.com
Norway
=======================================================================
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 May 15 08:14:25 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA12401 for info-performer-dist@holodeck.engr.sgi.com; Fri, 15 May 1998 07:50: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 HAA12374 for <info-performer@holodeck.engr.sgi.com>; Fri, 15 May 1998 07:50:24 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA78926
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 15 May 1998 07:50:25 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from netcom12.netcom.com (netcom12.netcom.com [192.100.81.124]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id HAA05494
	for <info-performer@sgi.com>; Fri, 15 May 1998 07:50:24 -0700 (PDT)
	mail_from (cutt@netcom.com)
Received: (from cutt@localhost)
	by netcom12.netcom.com (8.8.5-r-beta/8.8.5/(NETCOM v1.02)) id HAA23371;
	Fri, 15 May 1998 07:50:19 -0700 (PDT)
Date: Fri, 15 May 1998 07:50:19 -0700 (PDT)
From: "Paul S. Cutt" <cutt@netcom.com>
Subject: Re: accurate Joystick HArdware needed
To: ruediger polster <rpolster@blue-space.de>
cc: info-performer@sgi.com
In-Reply-To: <355C2585.E706E161@blue-space.de>
Message-ID: <Pine.3.89.9805150757.A23106-0100000@netcom12>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: QUOTED-PRINTABLE
Status: O


To ruediger and performer group,

We supply drivers and joysticks that work with performer. Check out
our web site www.xtensory.com for our universal VR device API for performer=

From guest  Fri May 15 09:43:46 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA12879 for info-performer-dist@holodeck.engr.sgi.com; Fri, 15 May 1998 09: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 JAA12852 for <info-performer@holodeck.engr.sgi.com>; Fri, 15 May 1998 09:22:52 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA09338
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 15 May 1998 09:22:52 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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 JAA12796
	for <info-performer@sgi.com>; Fri, 15 May 1998 09:22: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 (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA92745;
	Fri, 15 May 1998 09:22:50 -0700 (PDT)
	mail_from (dorbie@sgi.com)
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 JAA08799; Fri, 15 May 1998 09:22:50 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <355C6BD9.83531D2E@sgi.com>
Date: Fri, 15 May 1998 09:22: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: sewell@siscom.net
CC: info-performer@sgi.com
Subject: Re: Problems with Z-buffer.
References: <355C4B7A.7F74F31A@siscom.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Kenneth Sewell wrote:
> 
>     I have been working on a flight sim that loads in several
> rectangular patches of terrain.  The problem is that the z-buffer
> works correctly for the elements of each patch individually but
> not between the elements of two different patches.  I apologize
> if I'm not being very clear, I'll give an example.  If I have two
> patches A and B (each of them made up of a few thousand
> polygons) with A being closer to the viewer than B.  All of
> the polygons in A have been rendered properly with respect
> to each other, all of the polygons of B have been rendered
> properly with respect to each other.  However parts of B
> that should be hidden behind A, are drawn as though they
> are nearer.  This only happens to part of B, the rest of it is
> behind A, like it should be.  I am loading all of the patches
> at the same time and they are all children of one DCS node.
> I would appreciate any help you can offer.  Thanks.
> 

This is very strange.

Are you sure that you have a zbuffer, could you be getting lucky
with the order of the polygons and just seeing a painters effect
but the tiles are in the wrong order and betray what's really happening?

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 May 15 10:25:07 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA13033 for info-performer-dist@holodeck.engr.sgi.com; Fri, 15 May 1998 10:09: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 KAA13006 for <info-performer@holodeck.engr.sgi.com>; Fri, 15 May 1998 10:09:30 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA30163
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 15 May 1998 10:09:29 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from acusoft.com (acusoft.acusoft.com [205.187.235.130]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id KAA02707
	for <info-performer@sgi.com>; Fri, 15 May 1998 10:09:28 -0700 (PDT)
	mail_from (miller@acusoft.com)
Received: from distest by acusoft.com (5.x/SMI-SVR4)
	id AA03583; Fri, 15 May 1998 13:09:27 -0400
Received: by distest (950413.SGI.8.6.12) id NAA18031; Fri, 15 May 1998 13:09:26 -0400
Date: Fri, 15 May 1998 13:09:26 -0400 (EDT)
From: "Thomas M. Miller" <miller@acusoft.com>
X-Sender: miller@distest
To: sewell@siscom.net
Cc: info-performer@sgi.com
Subject: Re: Problems with Z-buffer.
In-Reply-To: <355C6BD9.83531D2E@sgi.com>
Message-Id: <Pine.SGI.3.91.980515130732.18010A-100000@distest>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

> Kenneth Sewell wrote:
> > 
> >     I have been working on a flight sim that loads in several
> > rectangular patches of terrain.  The problem is that the z-buffer
> > works correctly for the elements of each patch individually but
> > not between the elements of two different patches.  I apologize
> > if I'm not being very clear, I'll give an example.  If I have two
> > patches A and B (each of them made up of a few thousand
> > polygons) with A being closer to the viewer than B.  All of
> > the polygons in A have been rendered properly with respect
> > to each other, all of the polygons of B have been rendered
> > properly with respect to each other.  However parts of B
> > that should be hidden behind A, are drawn as though they
> > are nearer.  This only happens to part of B, the rest of it is
> > behind A, like it should be.  I am loading all of the patches
> > at the same time and they are all children of one DCS node.
> > I would appreciate any help you can offer.  Thanks.
> > 

Is It possible that you have a pfLayer Node in the tree that might cause this?

Or maybe some PFSTATE_DECAL mode set in your pfGeoStates?


--TMIV
=======================================================================
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 May 15 12:21:16 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA13371 for info-performer-dist@holodeck.engr.sgi.com; Fri, 15 May 1998 12:00: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 MAA13344 for <info-performer@holodeck.engr.sgi.com>; Fri, 15 May 1998 12:00:44 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA06930
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 15 May 1998 12:00:44 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from dillinger.io.com (dillinger.io.com [199.170.88.11]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id MAA22781
	for <info-performer@sgi.com>; Fri, 15 May 1998 12:00:41 -0700 (PDT)
	mail_from (markc@io.com)
From: markc@io.com
Received: from localhost (markc@localhost)
	by dillinger.io.com (8.8.7/8.8.5) with SMTP id OAA28891
	for <info-performer@sgi.com>; Fri, 15 May 1998 14:00:40 -0500 (CDT)
X-Authentication-Warning: dillinger.io.com: markc owned process doing -bs
Date: Fri, 15 May 1998 14:00:40 -0500 (CDT)
To: info-performer@sgi.com
Subject: pfLPStateVal -- no effect from PFLPS_INTENSITY
Message-ID: <Pine.BSF.3.96.980515134726.28542A-100000@dillinger.io.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

Hello,


  I have a number of runway, and taxiway lights -- which need to have
variable intensities.  Using pfLPStateVal(lps,PFLPS_INTENSITY, someval
(0.0 to 1.0) ) has no effect at all.  Nothing is display listed, and the
code for lightpoint creation is almost identical to that in
/usr/share/Performer/src/C.

  The only oddity is that we cache the pfLPState in the "parent" geode's
userdata, and the fetch it back.

  Has anyone else seen this kind of problem ?  I've checked the archives,
and have not found much to point me to a solution.

Thanks,

Mark Cartwright
markc@io.com
mac@wesson.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 May 15 12:22:47 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA13413 for info-performer-dist@holodeck.engr.sgi.com; Fri, 15 May 1998 12:13: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 MAA13386 for <info-performer@holodeck.engr.sgi.com>; Fri, 15 May 1998 12:13:03 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA12327
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 15 May 1998 12:13:02 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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 MAA27597; Fri, 15 May 1998 12:12:56 -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 OAA23935; Fri, 15 May 1998 14:12:54 -0500 (CDT)
Date: Fri, 15 May 1998 14:12:32 -0500 (CDT)
From: Steve Baker <sbaker@link.com>
X-Sender: steve@sutcliffe.bgm.link.com
Reply-To: Steve Baker <sbaker@link.com>
To: Angus Dorbie <dorbie@sgi.com>
cc: sewell@siscom.net, info-performer@sgi.com
Subject: Re: Problems with Z-buffer.
In-Reply-To: <355C6BD9.83531D2E@sgi.com>
Message-ID: <Pine.SGI.3.96.980515140355.13910A-100000@sutcliffe.bgm.link.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

On Fri, 15 May 1998, Angus Dorbie wrote:

> Kenneth Sewell wrote:
> > 
> >     I have been working on a flight sim that loads in several
> > rectangular patches of terrain.  The problem is that the z-buffer
> > works correctly for the elements of each patch individually but
> > not between the elements of two different patches.  I apologize
> > if I'm not being very clear, I'll give an example.  If I have two
> > patches A and B (each of them made up of a few thousand
> > polygons) with A being closer to the viewer than B.  All of
> > the polygons in A have been rendered properly with respect
> > to each other, all of the polygons of B have been rendered
> > properly with respect to each other.  However parts of B
> > that should be hidden behind A, are drawn as though they
> > are nearer.  This only happens to part of B, the rest of it is
> > behind A, like it should be.  I am loading all of the patches
> > at the same time and they are all children of one DCS node.
> > I would appreciate any help you can offer.  Thanks.
> > 
> 
> This is very strange.
 
It certainly is.

> Are you sure that you have a zbuffer, could you be getting lucky
> with the order of the polygons and just seeing a painters effect
> but the tiles are in the wrong order and betray what's really happening?
 
I think he must have a Z buffer of some kind because he says:

> > However parts of B
> > that should be hidden behind A, are drawn as though they
> > are nearer.  This only happens to part of B, the rest of it is
> > behind A, like it should be.

If *some* of B comes out in front and some behind then we probably
have to assume that some kind of pixel occultation is going on.

Although it's possible that Performer is sorting polygons by
GeoState - which might explain this behaviour in the absence
of a Z buffer.

Another possibility is that the terrain is being rendered
in some manner that makes Performer see some of the polygons
as translucent - so they are sorted into a different bucket
and rendered at the end.

I would suggest that perhaps the most likely reason for this
strange behaviour is that the Z buffer *is* present but it's
precision is really, really, terrible. As all who read this
list regularly will know, it's very easy for beginners to
get this wrong.

Kenneth: What near and far clip planes are you using?
         Does your terrain use a variety of pfGeoState's
         or does it all share a single pfGeoState?

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 May 15 13:29:24 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; Fri, 15 May 1998 13:09: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 NAA13740 for <info-performer@holodeck.engr.sgi.com>; Fri, 15 May 1998 13:09:10 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA33803
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 15 May 1998 13:09:08 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from davinci.cnart.mx (davinci.cnart.mx [200.15.13.1]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id NAA18682
	for <info-performer@sgi.com>; Fri, 15 May 1998 13:09:05 -0700 (PDT)
	mail_from (garcianv@davinci.cnart.mx)
Received: from marcos by davinci.cnart.mx via SMTP (951211.SGI.8.6.12.PATCH1502/940406.SGI.AUTO)
	 id PAA18364; Fri, 15 May 1998 15:08:12 -0700
Sender: garcianv@davinci.cnart.mx
Message-ID: <355CBCCC.41C6@correo.cnart.mx>
Date: Fri, 15 May 1998 15:08:12 -0700
From: Jose Luis Garcia Nava <garcianv@davinci.cnart.mx>
Organization: Centro Multimedia, CNA.
X-Mailer: Mozilla 3.04C-SGI (X11; I; IRIX 6.2 IP22)
MIME-Version: 1.0
To: Sheldon Brown <sbrown@nestor.ucsd.edu>
CC: info-performer@sgi.com
Subject: Tcl/Tk and Performer.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Hi pfPeople,

we are trying to develop a simple Performer application that reads
commands from a Tcl/Tk application.

At this moment, the Tcl/Tk program reads input data from a serial port
device, then translates this data into alpha-numeric strings and send
these strings to a c-based program (already started) that generates and
plays sound files.

I am sure we can send those alpha-numeric strings also to a Performer
application to modify visual appearence of certain 3D models, but I do
not know how to proceed. I think I need to use pfutil event handling
features to get the strings into Performer, then use this data to modify
DCS already associated to my 3D models. As you can see, there is a lot
of work from this generic (and maybe wrong) idea to programming stage.
Any advise on how to retrieve strings from memory by pfutil will be
appreciated.

Thanks,

Jose Luis.


--
Jose Luis Garcia Nava
Jefe del Taller de Realidad Virtual
Centro Multimedia, CNA.
Tel. +52(5)420-4503 Fax. +52(5)420-4456
E-mail: garcianv@correo.cnart.mx
=======================================================================
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 May 15 14:55:34 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA13987 for info-performer-dist@holodeck.engr.sgi.com; Fri, 15 May 1998 14:33:27 -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 OAA13960 for <info-performer@holodeck.engr.sgi.com>; Fri, 15 May 1998 14:33:25 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA69380
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 15 May 1998 14:33:25 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from austin.cs.unc.edu (austin.cs.unc.edu [152.2.128.87]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id OAA22569
	for <info-performer@sgi.com>; Fri, 15 May 1998 14:33:22 -0700 (PDT)
	mail_from (zhangh@cs.unc.edu)
Received: from pleco.cs.unc.edu (pleco.cs.unc.edu [152.2.133.196])
	by austin.cs.unc.edu (8.8.8/8.8.8) with ESMTP id RAA26660;
	Fri, 15 May 1998 17:33:16 -0400 (EDT)
Received: (from zhangh@localhost)
	by pleco.cs.unc.edu (8.8.8/8.8.8) id RAA03789;
	Fri, 15 May 1998 17:33:11 -0400 (EDT)
From: Hansong Zhang <zhangh@cs.unc.edu>
Message-Id: <199805152133.RAA03789@pleco.cs.unc.edu>
Subject: Re: Tcl/Tk and Performer.
To: garcianv@davinci.cnart.mx (Jose Luis Garcia Nava)
Date: Fri, 15 May 1998 17:33:10 -0400 (EDT)
Cc: sbrown@nestor.ucsd.edu, info-performer@sgi.com
In-Reply-To: <355CBCCC.41C6@correo.cnart.mx> from "Jose Luis Garcia Nava" at May 15, 98 03:08:12 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Status: O

> 
> At this moment, the Tcl/Tk program reads input data from a serial port
> device, then translates this data into alpha-numeric strings and send
> these strings to a c-based program (already started) that generates and
> plays sound files.
> 
> I am sure we can send those alpha-numeric strings also to a Performer
> application to modify visual appearence of certain 3D models, but I do
> not know how to proceed. I think I need to use pfutil event handling
> features to get the strings into Performer, then use this data to modify
> DCS already associated to my 3D models. As you can see, there is a lot
> of work from this generic (and maybe wrong) idea to programming stage.
> Any advise on how to retrieve strings from memory by pfutil will be
> appreciated.
>

you've already translated serial-port data into alpha-numeric strings.
what about translating them into X events and send them to the performer
application?
=======================================================================
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 May 15 15:11:13 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA14063 for info-performer-dist@holodeck.engr.sgi.com; Fri, 15 May 1998 14:50: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 OAA14036 for <info-performer@holodeck.engr.sgi.com>; Fri, 15 May 1998 14:50:32 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA77539
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 15 May 1998 14:50:31 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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 OAA01194
	for <info-performer@sgi.com>; Fri, 15 May 1998 14:50:29 -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 QAA25727; Fri, 15 May 1998 16:49:14 -0500
Sender: mew@paradigmsim.com
Message-ID: <355CB85A.446B@paradigmsim.com>
Date: Fri, 15 May 1998 16:49:14 -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: Jose Luis Garcia Nava <garcianv@davinci.cnart.mx>
CC: Sheldon Brown <sbrown@nestor.ucsd.edu>, info-performer@sgi.com
Subject: Re: Tcl/Tk and Performer.
References: <355CBCCC.41C6@correo.cnart.mx>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Instead of reading and parsing strings in your Performer app, I'd
suggest putting a Tcl interpreter in your app.  Tcl/Tk provides an
interprocess communication mechanism, and it will do the work of event
handling, parsing and evaluating the strings.  Tcl/Tk was designed for
this.

If I had to start from scratch, the approach I would use is to:
1) create a Tcl/Tk interpreter in the Performer app,
2) create Tcl command bindings for the functionality to be invoked at
runtime,
3) register those commands with the interpreter,
4) during the sim loop, invoke Tcl_DoOneEvent() til all events handled.

This results in a Performer app that can now process commands sent to it
using the Tcl/Tk "send" command.  Tcl_DoOneEvent() will take care of the
event handling, and invoking the registered Tcl commands.

But no need to start from scratch: Paradigm has a vgGift called "pfTcl",
which does those steps, and includes a set of Tcl bindings for nearly
all the Performer API.  So by adding a few lines to a Performer app, you
have access to the Performer API at runtime.  pfTcl is part of the vgTcl
package, which you can get from 
ftp://ftp.paradigmsim.com/pub/outgoing/vggifts/vgtcl/vgtcl_OMEGA1.tardist
Then see /usr/sgitcl/PSI/include/pftcltk.h for the functions
pfInitTclTk() and pfUpdateTclTk().

Hope this helps.
Cheers
-- mew



Jose Luis Garcia Nava wrote:
> 
> Hi pfPeople,
> 
> we are trying to develop a simple Performer application that reads
> commands from a Tcl/Tk application.
> 
> At this moment, the Tcl/Tk program reads input data from a serial port
> device, then translates this data into alpha-numeric strings and send
> these strings to a c-based program (already started) that generates and
> plays sound files.
> 
> I am sure we can send those alpha-numeric strings also to a Performer
> application to modify visual appearence of certain 3D models, but I do
> not know how to proceed. I think I need to use pfutil event handling
> features to get the strings into Performer, then use this data to modify
> DCS already associated to my 3D models. As you can see, there is a lot
> of work from this generic (and maybe wrong) idea to programming stage.
> Any advise on how to retrieve strings from memory by pfutil will be
> appreciated.
> 
> Thanks,
> 
> Jose Luis.
> 
> --
> Jose Luis Garcia Nava
> Jefe del Taller de Realidad Virtual
> Centro Multimedia, CNA.
> Tel. +52(5)420-4503 Fax. +52(5)420-4456
> E-mail: garcianv@correo.cnart.mx

-- 
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  Fri May 15 18:11:33 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id RAA14641 for info-performer-dist@holodeck.engr.sgi.com; Fri, 15 May 1998 17:48: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 RAA14614 for <info-performer@holodeck.engr.sgi.com>; Fri, 15 May 1998 17:48:50 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id RAA41333
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 15 May 1998 17:48:49 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from proxy4.ba.best.com (proxy4.ba.best.com [206.184.139.15]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id RAA27452
	for <info-performer@sgi.com>; Fri, 15 May 1998 17:48:48 -0700 (PDT)
	mail_from (gcw@best.com)
Received: from gcw.vip.best.com (dynamic18.pm03.mv.best.com [209.24.240.146]) by proxy4.ba.best.com (8.8.8/8.8.BEST) with SMTP id RAA07403; Fri, 15 May 1998 17:48:14 -0700 (PDT)
Message-Id: <2.2.32.19900706130924.0069b74c@shell2.ba.best.com>
X-Sender: gcw@shell2.ba.best.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 06 Jul 1990 06:09:24 -0700
To: info-performer@sgi.com, Jose Luis Garcia Nava <garcianv@davinci.cnart.mx>
From: George Williams <gcw@best.com>
Subject: Re: Tcl/Tk and Performer.
Status: O



I have used a tool called SWIG (http://www.swig.org) to automatically generate
"wrappers" for the C Performer API for use in an interpreter called Python
(http://www.python.org)  I believe there is support for Tcl/Perl/Lisp
interpreters too.   
It only took a few minutes.  I would expect similar results for Tcl.

George W.
Fakespace, Inc.


George W.
At 03:08 PM 5/15/98 -0700, you wrote:
>Hi pfPeople,
>
>we are trying to develop a simple Performer application that reads
>commands from a Tcl/Tk application.
>
>At this moment, the Tcl/Tk program reads input data from a serial port
>device, then translates this data into alpha-numeric strings and send
>these strings to a c-based program (already started) that generates and
>plays sound files.
>
>I am sure we can send those alpha-numeric strings also to a Performer
>application to modify visual appearence of certain 3D models, but I do
>not know how to proceed. I think I need to use pfutil event handling
>features to get the strings into Performer, then use this data to modify
>DCS already associated to my 3D models. As you can see, there is a lot
>of work from this generic (and maybe wrong) idea to programming stage.
>Any advise on how to retrieve strings from memory by pfutil will be
>appreciated.
>
>Thanks,
>
>Jose Luis.
>
>
>--
>Jose Luis Garcia Nava
>Jefe del Taller de Realidad Virtual
>Centro Multimedia, CNA.
>Tel. +52(5)420-4503 Fax. +52(5)420-4456
>E-mail: garcianv@correo.cnart.mx
>=======================================================================
>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  Fri May 15 23:39:48 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id XAA15092 for info-performer-dist@holodeck.engr.sgi.com; Fri, 15 May 1998 23:16: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 XAA15065 for <info-performer@holodeck.engr.sgi.com>; Fri, 15 May 1998 23:16:38 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id XAA15292
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 15 May 1998 23:16:39 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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 XAA28322
	for <info-performer@sgi.com>; Fri, 15 May 1998 23:16:38 -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 (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id XAA19575;
	Fri, 15 May 1998 23:16:33 -0700 (PDT)
	mail_from (dorbie@sgi.com)
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 XAA01834; Fri, 15 May 1998 23:16:26 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <355D2F3A.2FDE4AC5@sgi.com>
Date: Fri, 15 May 1998 23:16:26 -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: sewell@siscom.net, info-performer@sgi.com
Subject: Re: Problems with Z-buffer.
References: <Pine.SGI.3.96.980515140355.13910A-100000@sutcliffe.bgm.link.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Steve Baker wrote:
> 
> On Fri, 15 May 1998, Angus Dorbie wrote:
> 
> > Kenneth Sewell wrote:
> > >
> > >     I have been working on a flight sim that loads in several
> > > rectangular patches of terrain.  The problem is that the z-buffer
> > > works correctly for the elements of each patch individually but
> > > not between the elements of two different patches.  I apologize
> > > if I'm not being very clear, I'll give an example.  If I have two
> > > patches A and B (each of them made up of a few thousand
> > > polygons) with A being closer to the viewer than B.  All of
> > > the polygons in A have been rendered properly with respect
> > > to each other, all of the polygons of B have been rendered
> > > properly with respect to each other.  However parts of B
> > > that should be hidden behind A, are drawn as though they
> > > are nearer.  This only happens to part of B, the rest of it is
> > > behind A, like it should be.  I am loading all of the patches
> > > at the same time and they are all children of one DCS node.
> > > I would appreciate any help you can offer.  Thanks.
> > >
> >
> > This is very strange.
> 
> It certainly is.
> 
> > Are you sure that you have a zbuffer, could you be getting lucky
> > with the order of the polygons and just seeing a painters effect
> > but the tiles are in the wrong order and betray what's really happening?
> 
> I think he must have a Z buffer of some kind because he says:
> 
> > > However parts of B
> > > that should be hidden behind A, are drawn as though they
> > > are nearer.  This only happens to part of B, the rest of it is
> > > behind A, like it should be.
> 
> If *some* of B comes out in front and some behind then we probably
> have to assume that some kind of pixel occultation is going on.
> 

Painters explains this perfectly, particularly if you consider state
sorting.

> Although it's possible that Performer is sorting polygons by
> GeoState - which might explain this behaviour in the absence
> of a Z buffer.

See, you even agree ;-)

Cheers,Angus.

> 
> Another possibility is that the terrain is being rendered
> in some manner that makes Performer see some of the polygons
> as translucent - so they are sorted into a different bucket
> and rendered at the end.
> 
> I would suggest that perhaps the most likely reason for this
> strange behaviour is that the Z buffer *is* present but it's
> precision is really, really, terrible. As all who read this
> list regularly will know, it's very easy for beginners to
> get this wrong.
> 
> Kenneth: What near and far clip planes are you using?
>          Does your terrain use a variety of pfGeoState's
>          or does it all share a single pfGeoState?
> 
> 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

-- 
"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  Sat May 16 03:41:20 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id DAA15500 for info-performer-dist@holodeck.engr.sgi.com; Sat, 16 May 1998 03:14: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 DAA15473 for <info-performer@holodeck.engr.sgi.com>; Sat, 16 May 1998 03:14:37 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id DAA65696
	for <info-performer@cthulhu.engr.sgi.com>;
	Sat, 16 May 1998 03:14:24 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from rex.copen.sgi.com ([144.253.215.23]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via SMTP id DAA01092
	for <info-performer@sgi.com>; Sat, 16 May 1998 03:14:20 -0700 (PDT)
	mail_from (svend@copen.sgi.com)
Received: by rex.copen.sgi.com (950413.SGI.8.6.12/930416.SGI)
	for info-performer@sgi.com id MAA00845; Sat, 16 May 1998 12:16:04 +0200
Resent-From: svend@copen.sgi.com (Svend Tang-Petersen)
Resent-Message-Id: <9805161216.ZM843@rex.copen.sgi.com>
Resent-Date: Sat, 16 May 1998 12:16:03 +0200
X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail)
Resent-To: info-performer@sgi.com
Received: from odin.corp.sgi.com by sgiden.copen.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI)
	for <svend@copen.sgi.com> id NAA07889; Thu, 14 May 1998 13:14:40 +0200
Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI)
	for <svend@copen.sgi.com> id EAA21629; Thu, 14 May 1998 04:11:28 -0700
Received: from daimi.aau.dk (daimi.aau.dk [130.225.16.1]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id EAA29723
	for <svend@copen.sgi.com>; Thu, 14 May 1998 04:11:26 -0700 (PDT)
	mail_from (kgronbak@daimi.aau.dk)
Received: from [130.225.17.106] (lima [130.225.17.106])
	by daimi.aau.dk (8.8.7/8.8.7) with ESMTP id NAA15214;
	Thu, 14 May 1998 13:11:18 +0200 (MET DST)
X-Sender: kgronbak@130.225.16.1
Message-Id: <v03130307b1804cd86dd3@[130.225.17.106]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Thu, 14 May 1998 13:15:25 +0200
To: sdb@Cs.Nott.AC.UK, c.greenhalgh@Cs.Nott.AC.UK, svend@copen.sgi.com,
        plundin@ios.chalmer.se, henrik.tramberend@gmd.de, martin.goebel@gmd.de,
        lef@sics.se, mike@jytko.jyu.fi
From: Kaj Gronbak <kgronbak@daimi.aau.dk@copen.sgi.com>
Subject: Job opportunity in Collaborative and Distributed Virtual
 Environments
Cc: jlk@daimi.aau.dk
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by sgi.sgi.com id EAA29723
Status: O

Dear Colleague,

I would kindly ask you to distribute this job announcement to whom you
think it would interest.  It is a post doc position in Collaborative and
Distributed Virtual Environments, a subject area where you and your
institution is known to have relevant competences.

Thanks in advance!

Best regards

Kaj Gr=F8nb=E6k

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


AARHUS UNIVERSITY, DENMARK.

CENTER FOR MULTIMEDIA


POST DOC position in distributed and collaborative virtual
environments


Applications are invited for a two year post doc position in the
project entitled Distributed multimedia technologies and applications
(DMM) managed at Aarhus University.  The position is in the area of
collaborative and distributed virtual environments. The position is
open for the period from September 1, 1998 to August 31, 2000.

The Center for Multimedia was recently established by the Danish
National Research Councils and has as its objective to strengthen
interdisciplinary Danish multimedia research. The center runs for a
period of 4 years from January 1, 1998 to December 31, 2001.

The applicant must contribute to research in the DMM project which
covers research in distributed multimedia technologies and
applications in the following domains: collaboration support for
distributed organizations, distributed education, and electronic
commerce. The main activity for the post doc will be to work with
support for distributed collaboration on objects and information
represented in 3D spaces.  Examples of possible applications are
industrial design support, virtual children playgrounds, and medicine.

Applicants should have a strong research record in areas such as
distributed virtual environments, collaborative VR, augmented reality,
3Dvisualization, internet based VR.The successful candidate should be
able to carry out original research incooperation with fellow
researchers in the project and to a limited extent to contribute to
teaching at Aarhus University.

A PhD degree (or the equivalent) obtained within the past five years
is a recommended pre-requisite.

Applications (3 copies) should include a curriculum vitae giving
evidence on which the evaluation of the applicant's scientific
qualifications can be based,  a complete list of publications,
together with three copies of publications (max. 8) which the
applicant selects as the most relevant for the application. and the
names of three scientists who could comment on the applicant's
capabilities. Other supportive material should also be submitted in
three copies. The applicant must, upon request, submit further
material required by the selection committee in its evaluation.

Applications including names of two references, and a short statement
of research interests should be addressed to Faculty of Science,
University of Aarhus, Ny Munkegade, Building 520, DK-8000 Aarhus C,
Denmark, and marked 212/5-131.

The deadline for the receipt of all application material is June 30,
1998.

For more information please contact Associate Professor, Kaj Gr=F8nb=E6k,
Department of Computer Science, email: kgronbak@daimi.aau.dk, phone:
+458942 3237.




----------------------------------------------------------------------
| Kaj Gronbak, Computer Science Department, Aarhus University        |
| Ny Munkegade 116, Bldg. 540, DK-8000 Aarhus C, DENMARK             |
| Email: kgronbak@daimi.aau.dk  | http://www.daimi.aau.dk/~kgronbak  |
| phone:  (+45) 8942 3188       | direct: (+45) 8942 3237            |
| telefax: (+45) 8942 3255      | home: (+45) 8616 4391              |
| cellular: (+45) 2149 5634     | SMS: 21495634@sms.tdm.dk           |
----------------------------------------------------------------------


=======================================================================
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 May 16 10:34:15 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA16242 for info-performer-dist@holodeck.engr.sgi.com; Sat, 16 May 1998 09:29: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 JAA16215 for <info-performer@holodeck.engr.sgi.com>; Sat, 16 May 1998 09:29:36 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA34648
	for <info-performer@cthulhu.engr.sgi.com>;
	Sat, 16 May 1998 09:29:36 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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 JAA22661
	for <info-performer@sgi.com>; Sat, 16 May 1998 09:29:32 -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 SAA10028
	for <info-performer@sgi.com>; Sat, 16 May 1998 18:29:29 +0200 (MDT)
Received: from pc-crccobr ([193.71.72.141]) by nocrc.abb.no (4.1/SMI-4.1)
	id AA00635; Sat, 16 May 98 18:26:20 +0100
Message-Id: <355DBE8C.5607@nocrc.abb.no>
Date: Sat, 16 May 1998 18:27:56 +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: SGI-PF Discussion Group <info-performer@sgi.com>
Subject: Job opportunity at ABB Corporate Research, Norway
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Hi folks

The Corporate Research Centre in ABB Norway is looking to hire one or
more people in order to build up competence in real-time systems and
virtual reality. The new people are needed to contribute to a number of
projects in the power distribution, offshore engineering and railway
train (ADtranz) divisions. 

Skills required are virtual reality systems development, software for
real-time systems, 3D graphics and human-computer interfaces. Previous
relevant experience is a must as is education to MSc or equivalent. We
use Performer, OpenGL, and RapidApp for development work on SGIs and are
beginning to look into developing in a cross-platform environment. So
exposure to NT development systems would be an advantage. 

Salary is competitive for Norway and re-location expenses are normally
offered. English is the standard business language in ABB but being able
to speak Norwegian (or being willing to try !) would be useful. If you
are interested, send me a letter/fax/email with a resume. I am happy to
answer any queries informally in the first instance.

ABB Corporate Research is the internal R&D division for the ABB group of
companies worldwide (Asea Brown Boveri). Last year, the ABB group had a
turn-over in excess of USD 35 B. The offices in Norway are located to
the west of Oslo and are very close to the airport at Fornebu.

Best 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  Mon May 18 10:39:15 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA19454 for info-performer-dist@holodeck.engr.sgi.com; Mon, 18 May 1998 10:36: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 KAA19427 for <info-performer@holodeck.engr.sgi.com>; Mon, 18 May 1998 10:36:43 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA38357
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 18 May 1998 10:36:41 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from quid.csd.sgi.com ([150.166.129.99]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA00140
	for <info-performer@sgi.com>; Mon, 18 May 1998 10:36:40 -0700 (PDT)
	mail_from (robj@quid.csd.sgi.com)
Received: (from robj@localhost) by quid.csd.sgi.com (980205.SGI.8.8.8/960327.SGI.AUTOCF) id KAA10238; Mon, 18 May 1998 10:35:24 -0700 (PDT)
From: "Rob Jenkins" <robj@quid.csd.sgi.com>
Message-Id: <9805181035.ZM10242@quid.csd.sgi.com>
Date: Mon, 18 May 1998 10:35:23 -0700
In-Reply-To: "Ong Tze Lin" <tzelin@nuno.singapore.sgi.com>
        "Re: SYSLOG-Warning" (May 12,  2:38am)
References: <199805120833.RAA01390@such.dst.nk-exa.co.jp> 
	<9805120238.ZM27565@nuno.singapore.sgi.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: "Ong Tze Lin" <tzelin@nuno.singapore.sgi.com>, info-performer@sgi.com,
        Masahiko Yamanaka <wryperf@such.dst.nk-exa.co.jp>
Subject: Re: SYSLOG-Warning
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

That particular error just means that the gfx pipe timed out, the FIFOs allow
for parts of the pipe being a bottleneck and there's some time period after
which it decides that the pipe is blocked downstream and that the FIFOs aren't
going to drain, ie the pipe is hung. A gfx pipe hang can be the result of bad
HW ( including badly seated HW as Ong Tze Lin points out ) but it can also be
as a result of a SW bug. I tend to always go through the same few steps
initially with these problems:

o Checking Patches

Always double check that the machine with the problem has the latest iR gfx
patch installed. It's vital to make sure that you're not chasing a problem that
is already fixed. Currently the latest released iR gfx patches are:

patch 2922: Onyx2 6.4 graphics rollup #5 including GVO support or
patch 2327: Onyx (not Onyx2) InfiniteReality 6.2 Fifth Release

o Checking Hardware

Check that the latest Onyx Diagnostics patch is installed. The newer the
diagnostics patch you have, the more likely it is that any HW problem will get
detected. Passing diagnostics doesn't mean you can be 100% sure that there's no
HW problem but it at least gives some confidence that HW is OK. Currently the
latest iR diagnostics patches are:

patch 2795: Onyx2 Diagnostics 7th release or
patch 2371: InfiniteReality (Onyx) Diagnostics Fifth Release

o Debugging the Pipe

If you've checked the patches and checked the HW and you still have a problem
then here's some suggestions for narrowing down the problem.

Try and describe the symptoms, these problems generally fall into a couple of
loose areas, some useful things to establish are:

Does the problem happen on one machine ? If possible try and reproduce on other
similar machines. If it really happens on > 1 similar machines then the chances
of it being a HW  problem are reduced.
Does the problem happen with one specific application ?
If it happens with the same application always, is it with the same combination
of actions ?
Does the pipe crash ( and then should restart, putting you back to the login
screen ) or does the pipe just hang in that the gfx locks up but the rest of
the machine is still fine ?
Did the same application used to run OK ? Did *any* gfx SW get changed ?

If you can check the above and log a support call at the same time ( support
should take you through at least the first 2 things anyway ) then you're well
on the way to getting this resolved. A majority now turn out to be known SW
problems fixed in the latest patches or some HW problem ( again sorted via a
support call ). If it turns out you have a new SW problem ( quite rare now )
then the fun begins :-)

The key to solving a new iR gfx pipe SW problem is a reproducible test case,
ideally that can be run at SGI. iR has a great utility 'Kona Post Mortem ( kpm
)' that dumps the state of the gfx pipe. There is a man page so you can look at
how to read the dumps yourself although they're really only useful to
engineering here so I won't go into great detail on what to look for. I can
give more detail on narrowing down a testcase though if needs be although
support can also help you do that.

I've dealt with 'a few' of these things :-) It seems a bore but it's never
worth skipping the first 2 stages fo checking patches then HW before embarking
down the path of debugging.

Cheers
Rob

On May 12,  2:38am, Ong Tze Lin wrote:
> Subject: Re: SYSLOG-Warning
> Hi
>
> Have you tried running irsaudit to pinpoint the problem?  I have come across
> this kind of error message several times and more often than not its due to a
> bad (or badly-seated) RM board.
>
> Run irsaudit as root off a laptop or dumb terminal, but not on the graphics
> console:
>
> First, stop graphics with /usr/gfx/stopgfx.
>
> Run /usr/diags/IR/bin/irsaudit and sit back while it churns away.  It will
take
> some time to complete and return, but it will display its test results along
> the way- you'll know if you have bad parts.
>
> Restart graphics with /usr/gfx/startgfx.
>
> Hope this helps.
>
> Tzelin
>
> On May 12,  5:33pm, Masahiko Yamanaka wrote:
> > Subject: SYSLOG-Warning
> > Hello all!
> >
> > Though this might be a simple H/W problem, I believe someone in this ML
> > know about this...
> >
> > One of my customers has Onyx2/iR and a Performer-based application.
> >
> > As running the app., sometimes the window disappears and SYSLOG says,
> >
> >      WARNING:IR0:Pipe hung: on TBUS or ARM activity
> >      WARNING:IR0:Timeout waiting for fifo to drain ( level == 0x70a)
> >
> > What does this mean, what's wrong?
> > Or should I explain more details? (Sorry, I have only above right now...)
> >
> > Any help will be greatly appreciated!
> >
> > Thank you,
> > --
> > M.Y.
> > =======================================================================
> > 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 Masahiko Yamanaka
>
>
>
> --
> Ong Tze Lin 				Technical Consultant
> Silicon Graphics ASEAN HQ		High-Performance Computer Graphics
> 89 Science Park Dr. #03-03 to 06
> The Rutherford, Singapore 118261	Tel: (065)777 3088  Fax: (065)779 3650
>
> =======================================================================
> 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



-- 
________________________________________________________________
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  Mon May 18 10:39:15 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA19420 for info-performer-dist@holodeck.engr.sgi.com; Mon, 18 May 1998 10:25: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 KAA19393 for <info-performer@holodeck.engr.sgi.com>; Mon, 18 May 1998 10:25:36 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA14176
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 18 May 1998 10:25:35 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA25279
	for <info-performer@sgi.com>; Mon, 18 May 1998 10:25:33 -0700 (PDT)
	mail_from (cjackson@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 MAA23301
	for <@arlut.utexas.edu:info-performer@sgi.com>; Mon, 18 May 1998 12:25:32 -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 MAA23289
	for <@ns1.arlut.utexas.edu:info-performer@sgi.com>; Mon, 18 May 1998 12:25:30 -0500 (CDT)
Received: by chagos (940816.SGI.8.6.9/940406.SGI.AUTO)
	 id MAA21199; Mon, 18 May 1998 12:25:26 -0500
Date: Mon, 18 May 1998 12:25:19 +36000
From: Chris Jackson <cjackson@arlut.utexas.edu>
To: info-performer@sgi.com
Subject: Going big and stereo
Message-ID: <Pine.SGI.3.90.980518120734.21108A-100000@chagos>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O


I'm developing an application that must be displayed at 1900x1200.  I am 
currently implementing stereo graphics, and this output configuration is 
causing a dilemma...

First off, quad-buffered stereo is out of the question because my 
hardware is restricted to "tiny" pixel depth at 1900x1200.  

So, I am resigned to using the top/bottom flavor.  

gfxinfo returns: 

Graphics board 0 is "KONAL" graphics.  
 Managed (":0.0") 1280x1024 
 Display has 2 channels 
 2 GEs (of 2), occmask = 0x03 
 4MB external BEF ram, 32bit path 
 1 RM8 board (of 1) 1/0/0/0 
 Texture Memory: 16MB/-/-/-
 Small pixel depth 
 32K cmap 
 Channel 0:  
 Origin = (0,0) 
 Video Output: 1280 pixels, 1024 lines, 72.00Hz (1280x1024_72.vfo)

In general, I am wondering if stereo is even possible in this format, and 
what method would be most effective.

Thank you for any help in advance.

Chris Jackson
Applied Research Laboratories - University of Texas at Austin
=======================================================================
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 May 18 12:11:44 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA19864 for info-performer-dist@holodeck.engr.sgi.com; Mon, 18 May 1998 11:52:38 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA19837 for <info-performer@holodeck.engr.sgi.com>; Mon, 18 May 1998 11:52:37 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA06794
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 18 May 1998 11:52:36 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA10324
	for <info-performer@sgi.com>; Mon, 18 May 1998 11:52:35 -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 (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA56785;
	Mon, 18 May 1998 11:52:34 -0700 (PDT)
	mail_from (dorbie@sgi.com)
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 LAA04679; Mon, 18 May 1998 11:52:33 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <35608371.2FCA8CD9@sgi.com>
Date: Mon, 18 May 1998 11:52: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: Chris Jackson <cjackson@arlut.utexas.edu>
CC: info-performer@sgi.com
Subject: Re: Going big and stereo
References: <Pine.SGI.3.90.980518120734.21108A-100000@chagos>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Chris Jackson wrote:
> 
> I'm developing an application that must be displayed at 1900x1200.  I am
> currently implementing stereo graphics, and this output configuration is
> causing a dilemma...
> 
> First off, quad-buffered stereo is out of the question because my
> hardware is restricted to "tiny" pixel depth at 1900x1200.
> 
> So, I am resigned to using the top/bottom flavor.
> 
> gfxinfo returns:
> 
> Graphics board 0 is "KONAL" graphics.
>  Managed (":0.0") 1280x1024
>  Display has 2 channels
>  2 GEs (of 2), occmask = 0x03
>  4MB external BEF ram, 32bit path
>  1 RM8 board (of 1) 1/0/0/0
>  Texture Memory: 16MB/-/-/-
>  Small pixel depth
>  32K cmap
>  Channel 0:
>  Origin = (0,0)
>  Video Output: 1280 pixels, 1024 lines, 72.00Hz (1280x1024_72.vfo)
> 
> In general, I am wondering if stereo is even possible in this format, and
> what method would be most effective.
> 
> Thank you for any help in advance.
> 

You are going to have to reduce resolution, which top_bottom (SRT_RECT)
does by definition in Y. The high field rate in stereo vofs require lots
of bandwidth. Also display devices don't support the kinds of line
rates you need for these vofs. So start with your display and work back
from there.

It looks like you have a 1RM Reality (not Infinite Reality) so you don't
have a lot of framebuffer but you could config 2 * 1280x1024
framebuffer. You should explore getting 2 projectors and twinning them
feeding left and right eyes from different channels on the DG to the
projectors which will remove the per channel bandwidth limits and solve
any projector line rate problems.

Even if you had more RMs and an Infinite REality you cannot do 1900x1200
60Hz stereo, you don't have the RM->DG bandwidth or the DAC bandwidth on
any
channel. You couldn't even do 2*1900x1200 channels because of the DG->RM
bandwidth limit unless you squeezed video field rate to 50Hz.

You can get monitors which will handle moderately high resolution,
we saw one here which could sync to 1280x1024 120Hz (ie 60Hz stereo) but
this is better than a 120KHz line rate and that means a very expensive
monitor.

So, figure out the display you need, figure out whether you can afford
to
reduce your line count and whether you need a monitor or projected
display,
with multiple of single video feeds then you'll have a better idea of
what
kind of system capabilities you need.

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 May 18 14:45:08 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA20270 for info-performer-dist@holodeck.engr.sgi.com; Mon, 18 May 1998 14:29:31 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id OAA20243 for <info-performer@holodeck.engr.sgi.com>; Mon, 18 May 1998 14:29:28 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA28097
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 18 May 1998 14:29:28 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA11972
	for <info-performer@sgi.com>; Mon, 18 May 1998 14:29:26 -0700 (PDT)
	mail_from (WRVO@chevron.com)
Received: (from uucp@localhost)
	by portalcp.chevron.com (8.8.8/8.8.8) id OAA20865
	for <info-performer@sgi.com>; Mon, 18 May 1998 14:29:25 -0700 (PDT)
Received: from unknown(146.27.64.202) by portalcp.chevron.com via smap (4.0a)
	id xmaa20400; Mon, 18 May 98 14:28:48 -0700
Received: from chvpk-msx04-b.sr.chevron.com (chvpk-msx04-b.sr.chevron.com [146.27.94.42])
	by schizoid.sr.chevron.com (8.8.7/8.8.5) with ESMTP id OAA13039
	for <info-performer@sgi.com>; Mon, 18 May 1998 14:28:38 -0700 (PDT)
Received: by chvpk-msx04-b.sr.chevron.com with Internet Mail Service (5.0.1460.8)
	id <K8Y75FHR>; Mon, 18 May 1998 14:29:38 -0700
Message-ID: <39EA81D694E0D111AC1A00805F6FBF0B0D8B0B@hou281-msx2.chevron.com>
From: "Volz, Bill (wrvo)" <WRVO@chevron.com>
To: "'info-performer@sgi.com'" <info-performer@sgi.com>
Subject: Drawing in pixels
Date: Mon, 18 May 1998 14:29:08 -0700
X-Mailer: Internet Mail Service (5.0.1460.8)
Status: O

I need to draw some objects that are measured in pixels - they do not have a
world coordinate size. Something similar to how pfHighlight with a highlight
style of points works. How does one do this?

Bill Volz - Senior Research Geophysicist
Chevron Petroleum Technology
Voice: (281)-596-2059 Fax: (281)-493-7088

=======================================================================
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 May 19 06:28:35 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id FAA21650 for info-performer-dist@holodeck.engr.sgi.com; Tue, 19 May 1998 05:54:21 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id FAA21622 for <info-performer@holodeck.engr.sgi.com>; Tue, 19 May 1998 05:54:20 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id FAA42685
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 19 May 1998 05:54:19 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id FAA02976
	for <info-performer@sgi.com>; Tue, 19 May 1998 05:54:09 -0700 (PDT)
	mail_from (rioj7@fel.tno.nl)
Received: by dewey.fel.tno.nl; id OAA04785; Tue, 19 May 1998 14:54:17 +0200
Received: from s00sn1.fel.tno.nl(134.203.8.207) by dewey.fel.tno.nl via smap (4.1)
	id xma004672; Tue, 19 May 98 14:53:19 +0200
Received: (from rioj7@localhost)
	by s00sn1.fel.tno.nl (8.8.5/8.8.5) id OAA15794;
	Tue, 19 May 1998 14:52:07 +0200 (MET DST)
From: Mario Veraart <rioj7@fel.tno.nl>
Message-Id: <199805191252.OAA15794@s00sn1.fel.tno.nl>
Subject: pfDrawBin and pfDraw
To: info-performer@sgi.com (Performer)
Date: Tue, 19 May 1998 14:52:06 +0200 (MET DST)
Cc: rioj7@s00sn1.fel.tno.nl (Mario Veraart)
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Status: O

Hello pfAll,

I would like to implement a multipass algorithm and for this I have to
draw the geometry in a certain order. For this I want to use the bins
of a pfChannel. As an experiment I replaced the call of pfDraw with
the following two lines

	pfDrawBin(PFSORT_OPAQUE_BIN);
	pfDrawBin(PFSORT_TRANSP_BIN);

The result is that nothing gets drawn, only the sky and ground are
drawn. If I set the bin number explicitly then only the geometry in
the transparent bin is visible.

My questions

1: What is pfDraw() doing besides calling pfDrawBin() in the order
specified with setBinOrder()?

2: The programmers guide tells that it is possible to add more bins
but does not tell you how. Is a call to setBinOrder() with an unkown
bin number enough to create a new bin for this pfChannel?

3: If I have to rely on pfDraw() to draw the geometry how can I set up
the right GL calls to implement the wanted multipass algorithm?

Any help to solve this problem is appreciated.
I use Performer 2.0 on a REII. If Performer 2.2 is better on the point
of using bins I will have to upgrade.

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 May 19 09:15:06 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id IAA22097 for info-performer-dist@holodeck.engr.sgi.com; Tue, 19 May 1998 08:56:52 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id IAA22070 for <info-performer@holodeck.engr.sgi.com>; Tue, 19 May 1998 08:56:51 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id IAA80077
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 19 May 1998 08:56:50 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA01501
	for <info-performer@sgi.com>; Tue, 19 May 1998 08:55:07 -0700 (PDT)
	mail_from (ericb@symphony.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 LAA02739
	for <info-performer@sgi.com>; Tue, 19 May 1998 11:54:48 -0400 (EDT)
Received: from symphony.mitre.org (symphony45.mitre.org) by maestro.mitre.org (4.1/SMI-4.1)
	id AA18138; Tue, 19 May 98 11:54:47 EDT
Received: from pegasus.mitre.org by symphony.mitre.org (SMI-8.6/SMI-SVR4)
	id LAA08920; Tue, 19 May 1998 11:54:47 -0400
Received: by pegasus.mitre.org (SMI-8.6/SMI-SVR4)
	id LAA08655; Tue, 19 May 1998 11:54:46 -0400
From: Eric Brandwine <ericb@mitre.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Tue, 19 May 1998 11:54:46 -0400 (EDT)
To: info-performer@sgi.com
Subject: 3 channel projection system
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-Id: <13665.41431.487411.149311@pegasus>
Reply-To: ericb@mitre.org
Status: O

We have a medium fidelity cockpit simulator, and have just ordered a
number of hardware upgrades.

We currently have an Onyx Reality Station w/MCO, driving 3 projectors
on an ~150 degree arc.  The projectors display on 3 flat screens,
like \_/.

We just ordered an Onyx2 IR w/DG8, 3 new projectors w/contrast
modulation, and a single curved screen.  We want to do edge blending,
but are not sure of a couple of things.

1) Can the DG8 lay out channels in any geometry?  The MCO would allow
   you to pick resolution/channel count, but you were stuck with the
   layout they gave you (to fit in a 2kx2k virtual buffer).

   We run 3@960x680, with 3 screens tiled horizontally, while the 3
   channels are tiled vertically.

2) How should we set up Performer to drive this projection system?
   Right now, we have 3 channels defined, with the center as the
   master, the 2 side channels offset ~50 degrees.  This means 3
   rendering passes for our single pipeline.  Is there any way that we
   could define a single channel with a 150 degree field of view, and
   divide it across 3 outputs of the DG8?  Also, how should we get
   edge blenging working?  Right now, the 3 channels that we are
   displaying are not co-planar, so even if we were to increase the
   horizontal field of view per channel a bit, and overlap the
   projected images, the overlapped region would not match due to the
   different geometries.  Is this acceptable?  Is there some way to
   tell Performer to make some number of pixels on the edge of the
   channel the same as the next channel over?

Any help would be appreciated!

thanks,

ericb
-- 
 Eric Brandwine, Systems Engineer
 EricB@Mitre.org
 The MITRE Corporation, McLean VA  22102
 (703) 883-3319   FAX: (703) 883-1917
=======================================================================
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 May 19 10:36:54 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA22389 for info-performer-dist@holodeck.engr.sgi.com; Tue, 19 May 1998 10:20:09 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id KAA22362 for <info-performer@holodeck.engr.sgi.com>; Tue, 19 May 1998 10:20:08 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA25515
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 19 May 1998 10:20:07 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from remi.engr.sgi.com ([150.166.37.25]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id KAA07743
	for <info-performer@sgi.com>; Tue, 19 May 1998 10:20:06 -0700 (PDT)
	mail_from (remi@remi.engr.sgi.com)
Received: (from remi@localhost) by remi.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA04279; Tue, 19 May 1998 10:20:05 -0700
From: remi@remi.engr.sgi.com (Rémi Arnaud)
Message-Id: <199805191720.KAA04279@remi.engr.sgi.com>
Subject: Re: pfDrawBin and pfDraw
To: rioj7@fel.tno.nl (Mario Veraart)
Date: Tue, 19 May 1998 10:20:04 -0700 (PDT)
Cc: info-performer@sgi.com, rioj7@s00sn1.fel.tno.nl
In-Reply-To: <199805191252.OAA15794@s00sn1.fel.tno.nl> from "Mario Veraart" at May 19, 98 02:52:06 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

Mario Veraart wrote:
> 
> Hello pfAll,
> 
> I would like to implement a multipass algorithm and for this I have to
> draw the geometry in a certain order. For this I want to use the bins
> of a pfChannel. As an experiment I replaced the call of pfDraw with
> the following two lines
> 
> 	pfDrawBin(PFSORT_OPAQUE_BIN);
> 	pfDrawBin(PFSORT_TRANSP_BIN);
> 
> The result is that nothing gets drawn, only the sky and ground are
> drawn. If I set the bin number explicitly then only the geometry in
> the transparent bin is visible.
> 
> My questions
> 
> 1: What is pfDraw() doing besides calling pfDrawBin() in the order
> specified with setBinOrder()?

 pfDraw() draws everything that do not fall in a Bin, and then draw
 the bins.
 Since 2.2 you can use pfDrawBin(-1) to draw the objects that are
 not in a bin. Note, you have to use CULL separated from DRAW or
 CULL_DL_DRAW for the object not to be rendered immediately.
 
> 2: The programmers guide tells that it is possible to add more bins
> but does not tell you how. Is a call to setBinOrder() with an unkown
> bin number enough to create a new bin for this pfChannel?

 pfGeoSet::setDrawBin(b) will tell Performer to draw the geoset in
 the bin b. setBinOrder(b,order) will create the bin b and tell pfDraw
 in wich order to draw the bins.
 Note that each geoset has to have its own geostate for the bin mechanism
 to work. See 2.2 pfChannel man pages.

> 
> 3: If I have to rely on pfDraw() to draw the geometry how can I set up
> the right GL calls to implement the wanted multipass algorithm?
 Since 2.2 you can use pfDrawScene(). pfDraw() may call an internal
 multipass (for pfLightSource).
> 
> Any help to solve this problem is appreciated.
> I use Performer 2.0 on a REII. If Performer 2.2 is better on the point
> of using bins I will have to upgrade.

  A lot better, please upgrade.

    _  /              _             _ 
   |_) _ ._ _ 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 May 19 11:51:58 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA00887 for info-performer-dist@holodeck.engr.sgi.com; Tue, 19 May 1998 11:39:44 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA00859 for <info-performer@holodeck.engr.sgi.com>; Tue, 19 May 1998 11:39:43 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA63170
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 19 May 1998 11:08:02 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id LAA28067
	for <info-performer@sgi.com>; Tue, 19 May 1998 11:07:56 -0700 (PDT)
	mail_from (rioj7@fel.tno.nl)
Received: by dewey.fel.tno.nl; id UAA02787; Tue, 19 May 1998 20:08:08 +0200
Received: from s00sn1.fel.tno.nl(134.203.8.207) by dewey.fel.tno.nl via smap (4.1)
	id xma002774; Tue, 19 May 98 20:07:40 +0200
Received: (from rioj7@localhost)
	by s00sn1.fel.tno.nl (8.8.5/8.8.5) id UAA28976;
	Tue, 19 May 1998 20:06:27 +0200 (MET DST)
From: Mario Veraart <rioj7@fel.tno.nl>
Message-Id: <199805191806.UAA28976@s00sn1.fel.tno.nl>
Subject: Re: pfDrawBin and pfDraw
To: remi@remi.engr.sgi.com (R mi Arnaud)
Date: Tue, 19 May 1998 20:06:27 +0200 (MET DST)
Cc: info-performer@sgi.com (Performer)
In-Reply-To: <199805191720.KAA04279@remi.engr.sgi.com> from "Rémi Arnaud" at May 19, 98 10:20:04 am
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Status: O

Remi Arnaud wrote:
> Mario Veraart wrote:
> > 
> > I would like to implement a multipass algorithm and for this I have to
> > draw the geometry in a certain order. For this I want to use the bins
> > of a pfChannel. As an experiment I replaced the call of pfDraw with
> > the following two lines
> > 
> > 	pfDrawBin(PFSORT_OPAQUE_BIN);
> > 	pfDrawBin(PFSORT_TRANSP_BIN);
> > 
> > The result is that nothing gets drawn, only the sky and ground are
> > drawn. If I set the bin number explicitly then only the geometry in
> > the transparent bin is visible.
> > 
> > My questions
> > 
> > 1: What is pfDraw() doing besides calling pfDrawBin() in the order
> > specified with setBinOrder()?
> 
>  pfDraw() draws everything that do not fall in a Bin, and then draw
>  the bins.

But how can it be explained that if I set the bin number explicitly
and call pfDrawBin for every bin I see only the geometry of the
transparent bin? Is this not equivalent to a call to pfDraw()?

>  Since 2.2 you can use pfDrawBin(-1) to draw the objects that are
>  not in a bin. Note, you have to use CULL separated from DRAW or
>  CULL_DL_DRAW for the object not to be rendered immediately.
>  
> > 2: The programmers guide tells that it is possible to add more bins
> > but does not tell you how. Is a call to setBinOrder() with an unkown
> > bin number enough to create a new bin for this pfChannel?
> 
>  pfGeoSet::setDrawBin(b) will tell Performer to draw the geoset in
>  the bin b. setBinOrder(b,order) will create the bin b and tell pfDraw
>  in wich order to draw the bins.
>  Note that each geoset has to have its own geostate for the bin mechanism
>  to work. See 2.2 pfChannel man pages.

Is this also true for Performer 2.0? In the test program I used a few
simple flight models. So it could be that they share the geostate.

> > 3: If I have to rely on pfDraw() to draw the geometry how can I set up
> > the right GL calls to implement the wanted multipass algorithm?
>  Since 2.2 you can use pfDrawScene(). pfDraw() may call an internal
>  multipass (for pfLightSource).

> > Any help to solve this problem is appreciated.
> > I use Performer 2.0 on a REII. If Performer 2.2 is better on the point
> > of using bins I will have to upgrade.
> 
>   A lot better, please upgrade.

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  Tue May 19 11:51:58 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA00850 for info-performer-dist@holodeck.engr.sgi.com; Tue, 19 May 1998 11:35:37 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA00823 for <info-performer@holodeck.engr.sgi.com>; Tue, 19 May 1998 11:35:36 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA74733
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 19 May 1998 11:35:35 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from triavest.triavest.com (triavest.triavest.com [207.177.185.4]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id LAA09260
	for <info-performer@sgi.com>; Tue, 19 May 1998 11:35:30 -0700 (PDT)
	mail_from (kishore@triavest.com)
Received: from silver.triavest.com by triavest.triavest.com via ESMTP (950215.SGI.8.6.10/940406.SGI.AUTO)
	for <@triavest.triavest.com:info-performer@sgi.com> id LAA14801; Tue, 19 May 1998 11:37:26 -0700
Received: by silver.triavest.com (940816.SGI.8.6.9/940406.SGI.AUTO)
	for info-performer@sgi.com id LAA05325; Tue, 19 May 1998 11:24:53 -0700
From: "Anita Kishore" <kishore@triavest.com>
Message-Id: <9805191124.ZM5323@silver.triavest.com>
Date: Tue, 19 May 1998 11:24:50 -0700
X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail)
To: info-performer@sgi.com
Subject: texture memory and gmemusage
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

Hi:

	Does anybody know if the tool 'gmemusage' monitors texture
memory usage while running a performer application? And if so, then
how to track it?

thanks
-anita
=======================================================================
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 May 19 13:41:29 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA01607 for info-performer-dist@holodeck.engr.sgi.com; Tue, 19 May 1998 13:29:55 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id NAA01580 for <info-performer@holodeck.engr.sgi.com>; Tue, 19 May 1998 13:29:50 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA48209
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 19 May 1998 13:29:49 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from boito.videotron.net (boito.videotron.net [205.151.222.85]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA06246
	for <info-performer@sgi.com>; Tue, 19 May 1998 13:29:46 -0700 (PDT)
	mail_from (martel@signifi.com)
Received: from moreau.Signifi.com (ppp106.117.mmtl.videotron.net [207.253.117.106]) by boito.videotron.net (8.8.5/8.8.2) with SMTP id QAA20214 for <info-performer@sgi.com>; Tue, 19 May 1998 16:29:34 -0400 (EDT)
Sender: martel@boito.videotron.net
Message-ID: <3561DAF7.446B@signifi.com>
Date: Tue, 19 May 1998 15:18:15 -0400
From: Yves Martel <martel@signifi.com>
Organization: Signifi.gVR
X-Mailer: Mozilla 3.01SGoldC-SGI (X11; I; IRIX64 6.4 IP30)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: Re: Drawing in pixels
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Bill Volz wrote:

> I need to draw some objects that are measured in pixels - they do not have a
> world coordinate size. Something similar to how pfHighlight with a highlight
> style of points works. How does one do this?

If your problem is drawing an object on the screen so that it as the
corect dimentions in pixels, then you can use the "pixel" as a world 
coordinate unit in both x and z, the problem is, at what depth should
the 
object be to have the correct size ?

if the camera is oriented toward the +y axis,  it's a fairly straight
forward 
trigonometric problem, knowing the FOV and the screen size, you can
compute y 
the depth of your object:

     tan(fov/2) = (res_x/2) / y   ->    y = (res_x/2) / tan(fov/2) ;

	...

        float fov_h, fov_v ;
        int   res_x, res_y ;
        channel->getSize( &res_x, &res_y ) ;
        channel->getFOV( &fov_h, &fov_v ) ;
        float y = (res_x * 0.5f) / pfTan( fov_h*0.5f ) ;

	...

The next step is to keep the object aligned with the observer...


If your problem is, knowing the object position in space, what should be
it's
size so that it is "n" pixel big?  Then, you need to compute a scale
factor
from pixel-size to object-size.  It is again a very similar problem:
the object is at a distance "y", compute the screen width at that
distance,

	width_over_2 = tan(fov/2) * y

this width covers res_x/2 pixels, so the factor is: 

	1 pixel = (tan(fov/2) * y) / (res_x/2)



Does this help ?


_______________________________________________________
Yves Martel			Signifi.gVR
mailto:Martel@signifi.com       417 St-pierre suite 208
Tel: (514) 288-1453             Montreal, QC, CANADA
Fax: (514) 288-4112             H2Y 2M4
=======================================================================
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 May 19 14:01:05 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA01762 for info-performer-dist@holodeck.engr.sgi.com; Tue, 19 May 1998 13:47:16 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id NAA01735 for <info-performer@holodeck.engr.sgi.com>; Tue, 19 May 1998 13:47:15 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA58400
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 19 May 1998 13:47:15 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from remi.engr.sgi.com ([150.166.37.25]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id NAA14883
	for <info-performer@sgi.com>; Tue, 19 May 1998 13:47:13 -0700 (PDT)
	mail_from (remi@remi.engr.sgi.com)
Received: (from remi@localhost) by remi.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA05018; Tue, 19 May 1998 13:47:12 -0700
From: remi@remi.engr.sgi.com (Rémi Arnaud)
Message-Id: <199805192047.NAA05018@remi.engr.sgi.com>
Subject: Re: pfDrawBin and pfDraw
To: rioj7@fel.tno.nl (Mario Veraart)
Date: Tue, 19 May 1998 13:47:12 -0700 (PDT)
Cc: info-performer@sgi.com
In-Reply-To: <199805191806.UAA28976@s00sn1.fel.tno.nl> from "Mario Veraart" at May 19, 98 08:06:27 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

Mario Veraart wrote:
> 
> Remi Arnaud wrote:
> > Mario Veraart wrote:
> > > 
> > > I would like to implement a multipass algorithm and for this I have to
> > > draw the geometry in a certain order. For this I want to use the bins
> > > of a pfChannel. As an experiment I replaced the call of pfDraw with
> > > the following two lines
> > > 
> > > 	pfDrawBin(PFSORT_OPAQUE_BIN);
> > > 	pfDrawBin(PFSORT_TRANSP_BIN);
> > > 
> > > The result is that nothing gets drawn, only the sky and ground are
> > > drawn. If I set the bin number explicitly then only the geometry in
> > > the transparent bin is visible.
> > > 
> > > My questions
> > > 
> > > 1: What is pfDraw() doing besides calling pfDrawBin() in the order
> > > specified with setBinOrder()?
> > 
> >  pfDraw() draws everything that do not fall in a Bin, and then draw
> >  the bins.
> 
> But how can it be explained that if I set the bin number explicitly
> and call pfDrawBin for every bin I see only the geometry of the
> transparent bin? Is this not equivalent to a call to pfDraw()?

 Either you do not draw all the bins, or the objects do not fall in a
 bin.

 Also it may be an issue with the boggus logic used in 2.0/2.1, which has
 been fixed in 2.2
> 
> >  Since 2.2 you can use pfDrawBin(-1) to draw the objects that are
> >  not in a bin. Note, you have to use CULL separated from DRAW or
> >  CULL_DL_DRAW for the object not to be rendered immediately.
> >  
> > > 2: The programmers guide tells that it is possible to add more bins
> > > but does not tell you how. Is a call to setBinOrder() with an unkown
> > > bin number enough to create a new bin for this pfChannel?
> > 
> >  pfGeoSet::setDrawBin(b) will tell Performer to draw the geoset in
> >  the bin b. setBinOrder(b,order) will create the bin b and tell pfDraw
> >  in wich order to draw the bins.
> >  Note that each geoset has to have its own geostate for the bin mechanism
> >  to work. See 2.2 pfChannel man pages.
> 
> Is this also true for Performer 2.0? In the test program I used a few
> simple flight models. So it could be that they share the geostate.

 Its ok to share a geostate, just need to have one attached to each pfgeoset
 (pfGeoSet::setGState(pfGeoState *gstate))
> 
> > > 3: If I have to rely on pfDraw() to draw the geometry how can I set up
> > > the right GL calls to implement the wanted multipass algorithm?
> >  Since 2.2 you can use pfDrawScene(). pfDraw() may call an internal
> >  multipass (for pfLightSource).
> 
> > > Any help to solve this problem is appreciated.
> > > I use Performer 2.0 on a REII. If Performer 2.2 is better on the point
> > > of using bins I will have to upgrade.
> > 
> >   A lot better, please upgrade.
> 
> Mario Veraart
> =======================================================================
> 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  Tue May 19 18:16:23 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id SAA02690 for info-performer-dist@holodeck.engr.sgi.com; Tue, 19 May 1998 18:07:47 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id SAA02663 for <info-performer@holodeck.engr.sgi.com>; Tue, 19 May 1998 18:07:46 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id SAA84546
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 19 May 1998 18:07:46 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from star.mbc.co.kr ([203.227.48.129]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id SAA26252
	for <info-performer@sgi.com>; Tue, 19 May 1998 18:07:40 -0700 (PDT)
	mail_from (kangts@mbc.co.kr)
Received: from zkey ([203.238.228.212]) by star.mbc.co.kr (8.6.12h2/8.6.12) with SMTP id KAA10810 for <info-performer@sgi.com>; Wed, 20 May 1998 10:03:00 +0900
Message-ID: <35622DC2.CF2@mbc.co.kr>
Date: Wed, 20 May 1998 10:11:30 +0900
From: TaiSun kang <kangts@mbc.co.kr>
Reply-To: kangts@mbc.co.kr
Organization: MBC technical center
X-Mailer: Mozilla 3.01Gold (WinNT; I)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: NEED HELP: My program dies only on Onyx
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Dear Performers,

I am seeking help to solve a problem that I am trying
to solve for a week.

I developed a program using Performer 2.1.
The program reads in a scene description file and build
a scene graph from time to time. When a new scene description
file is read in, nodes in old scene graph is deleted and
new nodes are added. 

The program works well on Onyx2, O2, and Indigo2 Impact. But it dies
only on Onyx with segmenatation fault 
error message and core dump. Looked with gr_osview, it dies
when user memory uses around 1/3 of free memory (when user memory
indicates around 15,000 while 512 MB of main memory is installed.)

I suspect that textures are not freed well on Onyx.
Running program with scene descriptions files wit no textures
worked well. I am freeing textures with codes like

   pfDelete( tex );
   if ( tex->getRef() == 0 )
   {
       tex->freeImage();
       tex->apply();
   }

The program works well on Indigo2 Impact wit 4MB texture memory.
while the onyx has 16MB texutre memory.
The spec. of the Onyx is:
    R4400 CPU
    512 MB Main Memory
    Reality Engine II
    12 GE
    4 RM5 boards

I wonder if there is any patch that would solve the problem.
I will appreciate any help I can get.

Thanks in advance,

Byungsung Cho
bryce@chollian.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 May 20 09:26:56 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA04130 for info-performer-dist@holodeck.engr.sgi.com; Wed, 20 May 1998 09:18:21 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA04103 for <info-performer@holodeck.engr.sgi.com>; Wed, 20 May 1998 09:18:17 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA93473
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 20 May 1998 09:18:17 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from sgi5.cs.uiuc.edu (sgi5.cs.uiuc.edu [128.174.242.20]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA20536
	for <info-performer@sgi.com>; Wed, 20 May 1998 09:18:15 -0700 (PDT)
	mail_from (materick@sgi5.cs.uiuc.edu)
Received: from localhost (materick@localhost)
	by sgi5.cs.uiuc.edu (8.8.5/8.8.5) with SMTP id LAA03698
	for <info-performer@sgi.com>; Wed, 20 May 1998 11:18:12 -0500 (CDT)
Date: Wed, 20 May 1998 11:18:11 -0500 (CDT)
From: Craig Materick <materick@cs.uiuc.edu>
To: info-performer@sgi.com
Subject: openGL and Performer
Message-ID: <Pine.SGI.3.96.980520111440.3691A-100000@sgi5.cs.uiuc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

Just wondering if there is a straight-forward way to include an openGL
rendering routine(which I have) to draw stars as point sources into a
performer application which draws and animates the various bodies in the
solar system.  Currently, I am mapping a star map to a giant "Universe"
sphere, but this is slow and not too nice to look at.

Thanks in andvance for any information,

Craig Materick


=======================================================================
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 May 20 10:21:03 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA04371 for info-performer-dist@holodeck.engr.sgi.com; Wed, 20 May 1998 10:13:30 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id KAA04344 for <info-performer@holodeck.engr.sgi.com>; Wed, 20 May 1998 10:13:29 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA42479
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 20 May 1998 10:13:28 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA19266
	for <info-performer@sgi.com>; Wed, 20 May 1998 10:13: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 (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA71023;
	Wed, 20 May 1998 10:13:23 -0700 (PDT)
	mail_from (dorbie@sgi.com)
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 KAA08040; Wed, 20 May 1998 10:13:21 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <35630F31.E2B4C2CA@sgi.com>
Date: Wed, 20 May 1998 10:13:21 -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: Craig Materick <materick@cs.uiuc.edu>
CC: info-performer@sgi.com
Subject: Re: openGL and Performer
References: <Pine.SGI.3.96.980520111440.3691A-100000@sgi5.cs.uiuc.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Craig Materick wrote:
> 
> Just wondering if there is a straight-forward way to include an openGL
> rendering routine(which I have) to draw stars as point sources into a
> performer application which draws and animates the various bodies in the
> solar system.  Currently, I am mapping a star map to a giant "Universe"
> sphere, but this is slow and not too nice to look at.
> 
> Thanks in andvance for any information,
> 
> Craig Materick

Add the stars to the scene below a DCS, translate the DCS to the eye
position.
This will have the equivalent graphical effect of drawing at infinity so
you won't
need a huge sphere and will get better values for your CLIP plane
settings.

Disable depth writes and draw first to avoid zbuffer problems.

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 May 20 10:45:33 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA04487 for info-performer-dist@holodeck.engr.sgi.com; Wed, 20 May 1998 10:34:37 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id KAA04460 for <info-performer@holodeck.engr.sgi.com>; Wed, 20 May 1998 10:34:36 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA81788
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 20 May 1998 10:34:32 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id KAA29380
	for <info-performer@sgi.com>; Wed, 20 May 1998 10:34: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 KAA29909 for <info-performer@sgi.com>; Wed, 20 May 1998 10:45: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 RAA09726 for <@plateau.engr.multigen.com:info-performer@sgi.com>; Wed, 20 May 1998 17:35:57 GMT
Received: (from marcus@localhost) by logan.engr.multigen.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA01964 for info-performer@sgi.com; Wed, 20 May 1998 10:35:56 -0700
From: "Marcus Barnes" <marcus@multigen.com>
Message-Id: <9805201035.ZM1962@logan.engr.multigen.com>
Date: Wed, 20 May 1998 10:35:56 -0700
In-Reply-To: TaiSun kang <kangts@mbc.co.kr>
        "NEED HELP: My program dies only on Onyx" (May 20, 10:11am)
References: <35622DC2.CF2@mbc.co.kr>
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: NEED HELP: My program dies only on Onyx
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On May 20, 10:11am, TaiSun kang wrote:
>I suspect that textures are not freed well on Onyx.
>Running program with scene descriptions files wit no textures
>worked well. I am freeing textures with codes like
>
>   pfDelete( tex );
>   if ( tex->getRef() == 0 )
         ^^^
You are accessing potentially free memory here.

>   {
>       tex->freeImage();
>       tex->apply();
>   }

Change this to:

   if ( tex->getRef() == 0 )
   {
       tex->freeImage();
       tex->apply();
       pfDelete( tex );
   }

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-4103       +
=======================================================================
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 May 20 11:03:24 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA04668 for info-performer-dist@holodeck.engr.sgi.com; Wed, 20 May 1998 10:57:26 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id KAA04641 for <info-performer@holodeck.engr.sgi.com>; Wed, 20 May 1998 10:57:25 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA84714
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 20 May 1998 10:57:24 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA11113
	for <info-performer@sgi.com>; Wed, 20 May 1998 10:57:23 -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 (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA91150;
	Wed, 20 May 1998 10:57:23 -0700 (PDT)
	mail_from (dorbie@sgi.com)
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 KAA08090; Wed, 20 May 1998 10:57:22 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <35631982.EB174FBE@sgi.com>
Date: Wed, 20 May 1998 10:57: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: Marcus Barnes <marcus@multigen.com>
CC: info-performer@sgi.com
Subject: Re: NEED HELP: My program dies only on Onyx
References: <35622DC2.CF2@mbc.co.kr> <9805201035.ZM1962@logan.engr.multigen.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Marcus Barnes wrote:
> 
> On May 20, 10:11am, TaiSun kang wrote:
> >I suspect that textures are not freed well on Onyx.
> >Running program with scene descriptions files wit no textures
> >worked well. I am freeing textures with codes like
> >
> >   pfDelete( tex );
> >   if ( tex->getRef() == 0 )
>          ^^^
> You are accessing potentially free memory here.
> 
> >   {
> >       tex->freeImage();
> >       tex->apply();
> >   }
> 
> Change this to:
> 
>    if ( tex->getRef() == 0 )
>    {
>        tex->freeImage();
>        tex->apply();
>        pfDelete( tex );
>    }
> 

You probably don't want to call apply.
You are effectively deleting the currently bound texture.
Maybe something elegant happens but it seems like the wrong
thing to do (without checking Performer internals).

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 May 20 11:20:42 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA04833 for info-performer-dist@holodeck.engr.sgi.com; Wed, 20 May 1998 11:12:05 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA04806 for <info-performer@holodeck.engr.sgi.com>; Wed, 20 May 1998 11:12:05 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA00831
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 20 May 1998 11:12:04 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA18931
	for <info-performer@sgi.com>; Wed, 20 May 1998 11:12:03 -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 (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA90806;
	Wed, 20 May 1998 11:11:58 -0700 (PDT)
	mail_from (dorbie@sgi.com)
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 LAA08109; Wed, 20 May 1998 11:11:57 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <35631CED.1C3500D4@sgi.com>
Date: Wed, 20 May 1998 11:11:57 -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>, info-performer@sgi.com
Subject: Re: NEED HELP: My program dies only on Onyx
References: <35622DC2.CF2@mbc.co.kr> <9805201035.ZM1962@logan.engr.multigen.com> <35631982.EB174FBE@sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Angus Dorbie wrote:
> 
> Marcus Barnes wrote:
> >
> > On May 20, 10:11am, TaiSun kang wrote:
> > >I suspect that textures are not freed well on Onyx.
> > >Running program with scene descriptions files wit no textures
> > >worked well. I am freeing textures with codes like
> > >
> > >   pfDelete( tex );
> > >   if ( tex->getRef() == 0 )
> >          ^^^
> > You are accessing potentially free memory here.
> >
> > >   {
> > >       tex->freeImage();
> > >       tex->apply();
> > >   }
> >
> > Change this to:
> >
> >    if ( tex->getRef() == 0 )
> >    {
> >        tex->freeImage();
> >        tex->apply();
> >        pfDelete( tex );
> >    }
> >
> 
> You probably don't want to call apply.
> You are effectively deleting the currently bound texture.
> Maybe something elegant happens but it seems like the wrong
> thing to do (without checking Performer internals).


Also don't want to call apply from the application which is probably
where you should be deleting textures.

> 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 May 20 11:21:37 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA04915 for info-performer-dist@holodeck.engr.sgi.com; Wed, 20 May 1998 11:20:50 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA04888 for <info-performer@holodeck.engr.sgi.com>; Wed, 20 May 1998 11:20:49 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA94606
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 20 May 1998 11:20:48 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from sgi5.cs.uiuc.edu (sgi5.cs.uiuc.edu [128.174.242.20]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA23760
	for <info-performer@sgi.com>; Wed, 20 May 1998 11:20:47 -0700 (PDT)
	mail_from (materick@sgi5.cs.uiuc.edu)
Received: from localhost (materick@localhost)
	by sgi5.cs.uiuc.edu (8.8.5/8.8.5) with SMTP id NAA03873
	for <info-performer@sgi.com>; Wed, 20 May 1998 13:20:43 -0500 (CDT)
Date: Wed, 20 May 1998 13:20:43 -0500 (CDT)
From: Craig Materick <materick@cs.uiuc.edu>
To: info-performer@sgi.com
Subject: Re: openGL and Performer
In-Reply-To: <35630F31.E2B4C2CA@sgi.com>
Message-ID: <Pine.SGI.3.96.980520131539.3864A-100000@sgi5.cs.uiuc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

If the routine that draws the stars is just that, a routine that draws
points. How exactly does one tie that in to the scene graph so that it
draws all the points each frame?  Essentially, I have an openGL function
which draws points, and I need these points to be able to move and be
redrawn each frame according to some DCS in the scene graph.  How does the
routine to draw the points become a "node"?

Thanks,

Craig Materick


On Wed, 20 May 1998, Angus Dorbie wrote:

> Craig Materick wrote:
> > 
> > Just wondering if there is a straight-forward way to include an openGL
> > rendering routine(which I have) to draw stars as point sources into a
> > performer application which draws and animates the various bodies in the
> > solar system.  Currently, I am mapping a star map to a giant "Universe"
> > sphere, but this is slow and not too nice to look at.
> > 
> > Thanks in andvance for any information,
> > 
> > Craig Materick
> 
> Add the stars to the scene below a DCS, translate the DCS to the eye
> position.
> This will have the equivalent graphical effect of drawing at infinity so
> you won't
> need a huge sphere and will get better values for your CLIP plane
> settings.
> 
> Disable depth writes and draw first to avoid zbuffer problems.
> 
> 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  Wed May 20 11:52:42 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA05343 for info-performer-dist@holodeck.engr.sgi.com; Wed, 20 May 1998 11:43:28 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA05312 for <info-performer@holodeck.engr.sgi.com>; Wed, 20 May 1998 11:43:27 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA88944
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 20 May 1998 11:43:26 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id LAA06847
	for <info-performer@sgi.com>; Wed, 20 May 1998 11:43: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 LAA00889 for <info-performer@sgi.com>; Wed, 20 May 1998 11:54:33 -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 SAA11842 for <@plateau.engr.multigen.com:info-performer@sgi.com>; Wed, 20 May 1998 18:44:51 GMT
Received: (from marcus@localhost) by logan.engr.multigen.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA02119 for info-performer@sgi.com; Wed, 20 May 1998 11:44:50 -0700
From: "Marcus Barnes" <marcus@multigen.com>
Message-Id: <9805201144.ZM2117@logan.engr.multigen.com>
Date: Wed, 20 May 1998 11:44:50 -0700
In-Reply-To: Angus Dorbie <dorbie@sgi.com>
        "Re: NEED HELP: My program dies only on Onyx" (May 20, 10:57am)
References: <35622DC2.CF2@mbc.co.kr> 
	<9805201035.ZM1962@logan.engr.multigen.com> 
	<35631982.EB174FBE@sgi.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: NEED HELP: My program dies only on Onyx
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On May 20, 10:57am, Angus Dorbie wrote:
>You probably don't want to call apply.
>You are effectively deleting the currently bound texture.
>Maybe something elegant happens but it seems like the wrong
>thing to do (without checking Performer internals).

Yes. If should be sufficient to simply call pfDelete( pfTexture ). It should
safely handle deletion of the pfTexture and its associated image data.

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-4103       +
=======================================================================
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 May 20 13:26:27 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA05738 for info-performer-dist@holodeck.engr.sgi.com; Wed, 20 May 1998 13:19:00 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id NAA05711 for <info-performer@holodeck.engr.sgi.com>; Wed, 20 May 1998 13:18:59 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA65826
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 20 May 1998 13:18:59 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA18236
	for <info-performer@sgi.com>; Wed, 20 May 1998 13:18:58 -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 (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA55958;
	Wed, 20 May 1998 13:18:58 -0700 (PDT)
	mail_from (dorbie@sgi.com)
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 NAA08280; Wed, 20 May 1998 13:18:57 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <35633AB1.814AA3F3@sgi.com>
Date: Wed, 20 May 1998 13:18:57 -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: Craig Materick <materick@cs.uiuc.edu>
CC: info-performer@sgi.com
Subject: Re: openGL and Performer
References: <Pine.SGI.3.96.980520131539.3864A-100000@sgi5.cs.uiuc.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Craig Materick wrote:
> 
> If the routine that draws the stars is just that, a routine that draws
> points. How exactly does one tie that in to the scene graph so that it
> draws all the points each frame?  Essentially, I have an openGL function
> which draws points, and I need these points to be able to move and be
> redrawn each frame according to some DCS in the scene graph.  How does the
> routine to draw the points become a "node"?
> 
> Thanks,
> 
> Craig Materick
> 
> On Wed, 20 May 1998, Angus Dorbie wrote:
> 
> > Craig Materick wrote:
> > >
> > > Just wondering if there is a straight-forward way to include an openGL
> > > rendering routine(which I have) to draw stars as point sources into a
> > > performer application which draws and animates the various bodies in the
> > > solar system.  Currently, I am mapping a star map to a giant "Universe"
> > > sphere, but this is slow and not too nice to look at.
> > >
> > > Thanks in andvance for any information,
> > >
> > > Craig Materick
> >
> > Add the stars to the scene below a DCS, translate the DCS to the eye
> > position.
> > This will have the equivalent graphical effect of drawing at infinity so
> > you won't
> > need a huge sphere and will get better values for your CLIP plane
> > settings.
> >
> > Disable depth writes and draw first to avoid zbuffer problems.
> >
> > 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

Use a draw callback on a group bellow a pfnode, but I'd advise using
a geoset with PFGS_POINTS primitives and not calling the gl.

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 May 20 23:24:14 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id XAA07155 for info-performer-dist@holodeck.engr.sgi.com; Wed, 20 May 1998 23:01: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 XAA07128 for <info-performer@holodeck.engr.sgi.com>; Wed, 20 May 1998 23:01:46 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id XAA14473
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 20 May 1998 23:01:44 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from smtp.interlink.net (mailhost.interlink.net [198.168.54.58]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA12180
	for <info-performer@sgi.com>; Wed, 20 May 1998 23:01:43 -0700 (PDT)
	mail_from (glenn@tpg.interax.net)
Received: from tpg.interax.net (G7373.258.interax.net [199.202.239.142])
	by smtp.interlink.net (8.8.8/8.8.5) with ESMTP id CAA06804;
	Thu, 21 May 1998 02:04:32 -0400
Sender: glenn@smtp.interlink.net
Message-ID: <3563BD3F.E8A4F282@tpg.interax.net>
Date: Thu, 21 May 1998 01:35:59 -0400
From: Glenn Silver <glenn@tpg.interax.net>
Organization: TECHNOLOGY PLAYGROUP INC.
X-Mailer: Mozilla 4.05 [en] (X11; I; IRIX 6.3 IP32)
MIME-Version: 1.0
To: info-performer@sgi.com
CC: ruediger polster <rpolster@blue-space.de>
Subject: Re: accurate Joystick HArdware needed
References: <355C2585.E706E161@blue-space.de>
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 XAA39056
Status: O

ruediger polster wrote:

> Dear Performer starters, wizards and gurus
>
> One question  what have happens 1000 times last Yaer in the mailing lis=
t
> but I can=B4t find an Answer in the monthly archives.
>
> I need a Joystick as an Interface for Perfomer2.2 running IRIX 6.2 , 6.=
3
> and 6.4
>
> can anybody send me some good addresses.

We make the UNWINDER multifunction adapter - a small external device that
allows connecting 2 analog PC joysticks to an SGI serial port.  You can u=
se
a variety of standard PC gameport devices, like steering wheels, pedals,
etc..   Version 3.0 now includes Midi-Serial functionality for connecting
Midi devices, and Control-L for controlling camcorders/VTRs that use Sony=
's
LANC protocol.

Info is available on our website:
http://this.is/tpg/products/unwinder

There is also sample source code and drivers on the Performer 2.2 CD in t=
he
Friends directory, as well as Performer related info online:
http://this.is/tpg/products/unwinder/performer

Xtensory has now included the Unwinder in their XVS-Link driver package
that provides a universal VR device API for Performer.  See:
http://www.xtensory.com/xvslink.htm

Don't hesitate to contact me if you have questions....


Glenn


--
Glenn Silver
TECHNOLOGY PLAYGROUP INC.
http://this.is/tpg

email: glenn@tpg.interax.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  Thu May 21 04:35:11 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id EAA07688 for info-performer-dist@holodeck.engr.sgi.com; Thu, 21 May 1998 04:25: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 EAA07661 for <info-performer@holodeck.engr.sgi.com>; Thu, 21 May 1998 04:25:23 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id EAA38636
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 21 May 1998 04:25:23 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from imo29.mx.aol.com (imo29.mx.aol.com [198.81.17.73]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id EAA24057; Thu, 21 May 1998 04:25:17 -0700 (PDT)
	mail_from (PASociety@aol.com)
Received: from PASociety@aol.com
	by imo29.mx.aol.com (IMOv14.1) id KFKYa02462
	for <v-humans@ece.uwaterloo.ca>; Thu, 21 May 1998 06:51:15 -0400 (EDT)
From: PA Society <PASociety@aol.com>
Message-ID: <e003e2a1.35640724@aol.com>
Date: Thu, 21 May 1998 06:51:15 EDT
To: v-humans@ece.uwaterloo.ca
Mime-Version: 1.0
Subject: Bay Area Performance Animation Meeting Tonight (May 21st)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
X-Mailer: AOL 3.0 for Windows 95 sub 18
Status: O

          ****  IMPORTANT MEETING TONIGHT (MAY 21) ****

The "Bay Area Performance Animation Society" will be having
an open meeting at 7pm on May 21st at the new "Club i" at:
850 Folsom Street -  in San Francisco, CA.

The topic:     "An Overview of Motion Capture
                and Computer Technology in                   
                   Character Animation."

Our featured Speaker will be Bay Area PAS Director, Ron Fischer.
Ron is an eight year veteran of Silicon Graphics and now serves as
General Manager of "The Digital Actors Company."

Videos and a lively discussion will be provided and all interested parties
Are encouraged to attend free of charge.

The Performance Animation Society is devoted to bringing the arts of live
performance (acting) and puppetry together with the science of 3D character
animation by computer. Actors, puppeteers, computer artists and interested
parties make up the majority of PAS members.

For more information, The Performance Animation Society website can found
on the internet at:    

 http://www.pasociety.org/

Club i is an interactive cafe, with dining area and an array of
top-end PCs and software for rent.

***********       PLEASE PAS THE WORD !   ****************
=======================================================================
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 May 21 08:22:40 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id IAA08185 for info-performer-dist@holodeck.engr.sgi.com; Thu, 21 May 1998 08:17: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 IAA08158 for <info-performer@holodeck.engr.sgi.com>; Thu, 21 May 1998 08:17:09 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id IAA48702
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 21 May 1998 08:17:08 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from sgonyx.ita.es ([193.144.229.14]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA03787
	for <info-performer@sgi.com>; Thu, 21 May 1998 08:17:06 -0700 (PDT)
	mail_from (abadia@sgonyx.ita.es)
Received: (from abadia@localhost)
	by sgonyx.ita.es (8.8.8/8.8.8) id RAA29616
	for info-performer@sgi.com; Thu, 21 May 1998 17:16:00 +0200 (DST)
From: "Javier Abadia Miranda" <abadia@sgonyx.ita.es>
Message-Id: <9805211716.ZM29614@pandora.ita.es>
Date: Thu, 21 May 1998 17:16:00 +0000
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: info-performer@sgi.com
Subject: DBASE memory leaks revisited
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

Hello

I am experiencing some problems with dbase management.

I page in and out many pieces of a terrain dbase. And
I notice that memory consumption is always increasing.

With gmemusage I can see that what is actually getting
bigger is Irix memory space, particulary an area called
FS Cache.

I assume that this memory area is File System cache,
so I first thought that I had some files opened and not
closed.

I have revised my code and I am quite sure that I
close every open file.

Other "curious" effect is that if I stop moving
during a while, the FS cache starts going down.

Does Irix keep data from closed files in memory?

Is there a way to prevent Irix consuming this
phisical memory to speed up my application?


Thank you.

=======================================================================
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 May 21 08:43:13 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id IAA08252 for info-performer-dist@holodeck.engr.sgi.com; Thu, 21 May 1998 08:34: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 IAA08225 for <info-performer@holodeck.engr.sgi.com>; Thu, 21 May 1998 08:34:18 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id IAA22165
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 21 May 1998 08:34:17 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from sgonyx.ita.es ([193.144.229.14]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA11095
	for <info-performer@sgi.com>; Thu, 21 May 1998 08:34:09 -0700 (PDT)
	mail_from (abadia@sgonyx.ita.es)
Received: (from abadia@localhost)
	by sgonyx.ita.es (8.8.8/8.8.8) id RAA29727
	for info-performer@sgi.com; Thu, 21 May 1998 17:32:48 +0200 (DST)
From: "Javier Abadia Miranda" <abadia@sgonyx.ita.es>
Message-Id: <9805211732.ZM29725@pandora.ita.es>
Date: Thu, 21 May 1998 17:32:48 +0000
In-Reply-To: "Javier Abadia Miranda" <abadia@sgonyx.ita.es>
        "DBASE memory leaks revisited" (May 21,  5:16pm)
References: <9805211716.ZM29614@pandora.ita.es>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: info-performer@sgi.com
Subject: DBASE memory leaks revisited (more)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O


> Other "curious" effect is that if I stop moving
> during a while, the FS cache starts going down.
>

Sorry. This is not true. It was a silly mistake.

Bye!

=======================================================================
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 May 21 11:19:28 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA08864 for info-performer-dist@holodeck.engr.sgi.com; Thu, 21 May 1998 11:08: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 LAA08837 for <info-performer@holodeck.engr.sgi.com>; Thu, 21 May 1998 11:08:35 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA92290
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 21 May 1998 11:08:35 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA29697
	for <info-performer@sgi.com>; Thu, 21 May 1998 11:08:33 -0700 (PDT)
	mail_from (kishore@aimnet.com)
Received: (from kishore@localhost)
	by aimnet.com (8.8.8/8.8.6) id LAA03222;
	Thu, 21 May 1998 11:03:54 -0700 (PDT)
Date: Thu, 21 May 1998 11:03:54 -0700 (PDT)
From: Anita Kishore <kishore@aimnet.com>
Message-Id: <199805211803.LAA03222@aimnet.com>
To: abadia@sgonyx.ita.es, info-performer@sgi.com
Subject: Re: DBASE memory leaks revisited
Status: O

I am having exactly the same problem. In fact I have two open
support calls on this issue! It has been 4 to 5 days and no one has
been able to give any clarification on this. I have noticed
this with my performer application where I use the DBASE process
to delete and load new inventor models. I have also noticed this
with the pf2.2 sample program 'texmem' which allows you to
clear TRAM during run time. When this is done, the size as shown
by gmemusage of 'texmem' nearly doubles and IRIX size also 
goes up a lot. I don't understand what is going on, but
this surely slows up my other process (GUI) which uses thumbwheels,
invnetor rendering etc. a lot.

-anita
=======================================================================
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 May 21 11:59:23 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA09031 for info-performer-dist@holodeck.engr.sgi.com; Thu, 21 May 1998 11:48: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 LAA09004 for <info-performer@holodeck.engr.sgi.com>; Thu, 21 May 1998 11:48:51 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA36958
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 21 May 1998 11:48:51 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA18831; Thu, 21 May 1998 11:48:45 -0700 (PDT)
	mail_from (cjackson@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 NAA15314;
	Thu, 21 May 1998 13:48:44 -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 NAA15306;
	Thu, 21 May 1998 13:48:42 -0500 (CDT)
Received: by chagos (940816.SGI.8.6.9/940406.SGI.AUTO)
	 id NAA05079; Thu, 21 May 1998 13:48:41 -0500
Date: Thu, 21 May 1998 13:48:35 +36000
From: Chris Jackson <cjackson@arlut.utexas.edu>
To: Angus Dorbie <dorbie@sgi.com>
cc: info-performer@sgi.com
Subject: Re: Going big and stereo
In-Reply-To: <35608371.2FCA8CD9@sgi.com>
Message-ID: <Pine.SGI.3.90.980521133745.5043A-100000@chagos>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O



On Mon, 18 May 1998, Angus Dorbie wrote:

> 
> You are going to have to reduce resolution, which top_bottom (SRT_RECT)
> does by definition in Y. The high field rate in stereo vofs require lots
> of bandwidth. Also display devices don't support the kinds of line
> rates you need for these vofs. So start with your display and work back
> from there.


> 
> It looks like you have a 1RM Reality (not Infinite Reality) so you don't
> have a lot of framebuffer but you could config 2 * 1280x1024
> framebuffer. You should explore getting 2 projectors and twinning them
> feeding left and right eyes from different channels on the DG to the
> projectors which will remove the per channel bandwidth limits and solve
> any projector line rate problems.
> 
> Even if you had more RMs and an Infinite REality you cannot do 1900x1200
> 60Hz stereo, you don't have the RM->DG bandwidth or the DAC bandwidth on
> any
> channel. You couldn't even do 2*1900x1200 channels because of the DG->RM
> bandwidth limit unless you squeezed video field rate to 50Hz.
> 

The critical problem is that my diplay must be configured at 1900x1200.  
I can easily reduce resolution to 1280x1024 (or lower), but from what I 
understand, pixel depth will remain the same.  Isn't it true that a 
medium pixel depth is required for doublebuffered stereo?

Is there any way to implement stereo (top/bottom or otherwise) with graphics 
initialized to 1900x1200?  

At this point, I'm willing to use any resolution and any video field 
rate...

=======================================================================
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 May 21 12:34:22 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA09210 for info-performer-dist@holodeck.engr.sgi.com; Thu, 21 May 1998 12:31:01 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id MAA09183 for <info-performer@holodeck.engr.sgi.com>; Thu, 21 May 1998 12:31:00 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA25738
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 21 May 1998 12:30:59 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from scully.mugu.navy.mil ([143.113.1.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA08646
	for <info-performer@sgi.com>; Thu, 21 May 1998 12:30:57 -0700 (PDT)
	mail_from (ofriels1@qmsmtpgw.mugu.navy.mil)
Received: by scully.mugu.navy.mil; id PAA14716; Thu, 21 May 1998 15:31:03 -0400 (EDT)
Received: from tuvok.mugu.navy.mil(143.113.247.22) by scully.mugu.navy.mil via smap (4.1)
	id xma014712; Thu, 21 May 98 12:30:41 -0700
Received: from qmsmtpgw.mugu.navy.mil (qmsmtpgw1.mugu.navy.mil) by tuvok.mugu.navy.mil (4.1/SMI-4.1)
	id AA07587; Thu, 21 May 98 12:28:22 PDT
Message-Id: <n1316368245.42761@qmsmtpgw.mugu.navy.mil>
Date: 21 May 1998 12:26:35 -0700
From: "SCOTT OFRIEL" <ofriels1@qmsmtpgw.mugu.navy.mil>
Subject: Purple-ish Texture
To: "performer" <info-performer@sgi.com>
X-Mailer: Mail*Link SMTP-QM 4.0.0
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; Name="Message Body"
Content-Transfer-Encoding: quoted-printable
Status: O

Can anyone tell me why the textures are purple-ish on my Octane?

Thank you,
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  Thu May 21 12:34:20 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA09143 for info-performer-dist@holodeck.engr.sgi.com; Thu, 21 May 1998 12:23:11 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id MAA09116 for <info-performer@holodeck.engr.sgi.com>; Thu, 21 May 1998 12:23:10 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA71922
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 21 May 1998 12:23:10 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA05149
	for <info-performer@sgi.com>; Thu, 21 May 1998 12:23:09 -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 (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA33354;
	Thu, 21 May 1998 12:23:08 -0700 (PDT)
	mail_from (dorbie@sgi.com)
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 MAA08232; Thu, 21 May 1998 12:23:08 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <35647F1B.58992EA7@sgi.com>
Date: Thu, 21 May 1998 12:23:07 -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 Jackson <cjackson@arlut.utexas.edu>
CC: info-performer@sgi.com
Subject: Re: Going big and stereo
References: <Pine.SGI.3.90.980521133745.5043A-100000@chagos>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Chris Jackson wrote:
> 
> On Mon, 18 May 1998, Angus Dorbie wrote:
> 
> >
> > You are going to have to reduce resolution, which top_bottom (SRT_RECT)
> > does by definition in Y. The high field rate in stereo vofs require lots
> > of bandwidth. Also display devices don't support the kinds of line
> > rates you need for these vofs. So start with your display and work back
> > from there.
> 
> >
> > It looks like you have a 1RM Reality (not Infinite Reality) so you don't
> > have a lot of framebuffer but you could config 2 * 1280x1024
> > framebuffer. You should explore getting 2 projectors and twinning them
> > feeding left and right eyes from different channels on the DG to the
> > projectors which will remove the per channel bandwidth limits and solve
> > any projector line rate problems.
> >
> > Even if you had more RMs and an Infinite REality you cannot do 1900x1200
> > 60Hz stereo, you don't have the RM->DG bandwidth or the DAC bandwidth on
> > any
> > channel. You couldn't even do 2*1900x1200 channels because of the DG->RM
> > bandwidth limit unless you squeezed video field rate to 50Hz.
> >
> 
> The critical problem is that my diplay must be configured at 1900x1200.
> I can easily reduce resolution to 1280x1024 (or lower), but from what I
> understand, pixel depth will remain the same.  Isn't it true that a
> medium pixel depth is required for doublebuffered stereo?

Configure your managed area download ot eeprom, restart graphics and use
findvis or glxinfo to list supported visuals.

> 
> Is there any way to implement stereo (top/bottom or otherwise) with graphics
> initialized to 1900x1200?

If you can configure a managed area that size yes, but you would have to
compile
a video format and then all you've done is half the vertical resolution
in each
field so you've actually only got 1900x600 with old style stereo, (munus
any
blanking lines between fields)

> 
> At this point, I'm willing to use any resolution and any video field
> rate...

But what about your display, you started by saying that your display
must
be configured to 1900x1200.

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 May 21 12:48:13 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA09436 for info-performer-dist@holodeck.engr.sgi.com; Thu, 21 May 1998 12:44:20 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id MAA09409 for <info-performer@holodeck.engr.sgi.com>; Thu, 21 May 1998 12:44:19 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA25089
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 21 May 1998 12:44:18 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from lobotomy.evt.com ([204.133.157.33]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id MAA13921
	for <info-performer@sgi.com>; Thu, 21 May 1998 12:44:17 -0700 (PDT)
	mail_from (herod@evt.com)
Received: from evt.com (localhost [127.0.0.1]) by lobotomy.evt.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA06468; Thu, 21 May 1998 13:44:14 -0600
Sender: herod@evt.com
Message-ID: <3564840E.39817A5B@evt.com>
Date: Thu, 21 May 1998 13:44:14 -0600
From: Scott Herod <herod@evt.com>
X-Mailer: Mozilla 4.05 [en] (X11; I; IRIX 6.3 IP32)
MIME-Version: 1.0
To: Anita Kishore <kishore@aimnet.com>, info-performer@sgi.com
Subject: Re: DBASE memory leaks revisited
References: <199805211803.LAA03222@aimnet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Just to check what you mean...

You see this dramatic memory usage when you use the
pfuClearTextureMemory() call (which happens when you hit the "c"
while running 'texmem')?  That's depressing because I just adapted
the ClearTextureMemory call for use with Performer 2.04.  It only
makes GL calls (other than pfQuerySys the first time through).
I also see gmemusage going through the roof while I loop over
calls to pfuClearTextureMemory, but ps doesn't show any
increase in memory usage.  On the other hand, my test just 
core dumped with a bus error after ~5000 calls.  It looks like
I need to play with this problem myself some more.

Scott Herod
herod@evt.com

Anita Kishore wrote:
>   I have also noticed this
> with the pf2.2 sample program 'texmem' which allows you to
> clear TRAM during run time. When this is done, the size as shown
> by gmemusage of 'texmem' nearly doubles and IRIX size also
> goes up a lot. I don't understand what is going on, but
> this surely slows up my other process (GUI) which uses thumbwheels,
> invnetor rendering etc. a lot.
> 
> -anita
=======================================================================
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 May 21 12:48:16 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA09335 for info-performer-dist@holodeck.engr.sgi.com; Thu, 21 May 1998 12:40:37 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id MAA09308 for <info-performer@holodeck.engr.sgi.com>; Thu, 21 May 1998 12:40:36 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA27329
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 21 May 1998 12:40:35 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA12533
	for <info-performer@sgi.com>; Thu, 21 May 1998 12:40:34 -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 (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA17196;
	Thu, 21 May 1998 12:40:34 -0700 (PDT)
	mail_from (dorbie@sgi.com)
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 MAA09843; Thu, 21 May 1998 12:40:33 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <35648331.EEAB7462@sgi.com>
Date: Thu, 21 May 1998 12:40: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: Chris Jackson <cjackson@arlut.utexas.edu>, info-performer@sgi.com
Subject: Re: Going big and stereo
References: <Pine.SGI.3.90.980521133745.5043A-100000@chagos> <35647F1B.58992EA7@sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Angus Dorbie wrote:
> 
> Chris Jackson wrote:
> >
> > On Mon, 18 May 1998, Angus Dorbie wrote:
> >
> > >
> > > You are going to have to reduce resolution, which top_bottom (SRT_RECT)
> > > does by definition in Y. The high field rate in stereo vofs require lots
> > > of bandwidth. Also display devices don't support the kinds of line
> > > rates you need for these vofs. So start with your display and work back
> > > from there.
> >
> > >
> > > It looks like you have a 1RM Reality (not Infinite Reality) so you don't
> > > have a lot of framebuffer but you could config 2 * 1280x1024
> > > framebuffer. You should explore getting 2 projectors and twinning them
> > > feeding left and right eyes from different channels on the DG to the
> > > projectors which will remove the per channel bandwidth limits and solve
> > > any projector line rate problems.
> > >
> > > Even if you had more RMs and an Infinite REality you cannot do 1900x1200
> > > 60Hz stereo, you don't have the RM->DG bandwidth or the DAC bandwidth on
> > > any
> > > channel. You couldn't even do 2*1900x1200 channels because of the DG->RM
> > > bandwidth limit unless you squeezed video field rate to 50Hz.
> > >
> >
> > The critical problem is that my diplay must be configured at 1900x1200.
> > I can easily reduce resolution to 1280x1024 (or lower), but from what I
> > understand, pixel depth will remain the same.  Isn't it true that a
> > medium pixel depth is required for doublebuffered stereo?
> 
> Configure your managed area download ot eeprom, restart graphics and use
> findvis or glxinfo to list supported visuals.
> 
> >
> > Is there any way to implement stereo (top/bottom or otherwise) with graphics
> > initialized to 1900x1200?
> 
> If you can configure a managed area that size yes, but you would have to
> compile
> a video format and then all you've done is half the vertical resolution
> in each
> field so you've actually only got 1900x600 with old style stereo, (munus
> any
> blanking lines between fields)
> 
> >
> > At this point, I'm willing to use any resolution and any video field
> > rate...
> 
> But what about your display, you started by saying that your display
> must
> be configured to 1900x1200.

You could use DVR but only along one axis at anything over 1280x1024.

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 May 21 13:01:39 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA09720 for info-performer-dist@holodeck.engr.sgi.com; Thu, 21 May 1998 12:53:46 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id MAA09689 for <info-performer@holodeck.engr.sgi.com>; Thu, 21 May 1998 12:53:45 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA10877
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 21 May 1998 12:53:44 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from hpnfssvr.mdhc.mdc.com (hpnfssvr.PHX.AZ.BOEING.COM [130.38.244.3]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA17963
	for <info-performer@sgi.com>; Thu, 21 May 1998 12:53:42 -0700 (PDT)
	mail_from (erik.johnson@boeing.com)
Received: from boeing.com (rocko.mdhc.mdc.com [130.38.248.90]) by hpnfssvr.mdhc.mdc.com with ESMTP (8.7.6/8.7.3) id MAA26752 for <info-performer@sgi.com>; Thu, 21 May 1998 12:54:41 -0700 (MST)
Sender: johnson@hpnfssvr.mdhc.mdc.com
Message-ID: <3564866C.C832236E@boeing.com>
Date: Thu, 21 May 1998 12:54:20 -0700
From: Erik Johnson <erik.johnson@boeing.com>
X-Mailer: Mozilla 4.04 [en] (X11; I; IRIX 6.2 IP22)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: Re: DBASE memory leaks revisited
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Add my name to the list of people who have experienced this.  I'm using
Paradigm's Vega which uses Performer, but I'm seeing the same things.

Using amallinfo(pfGetSharedArena()) [from Oyvind Roa's email] shows me the
"total space in arena" creeps higher and higher when I page files until I hit
the max.

Using gmemusage shows the IRIX's FS Cache get bigger and bigger as well.  This
doesn't really surprise me, because that is it's job right?  To cache files
into memory?

I can reduce the problem a little by using [again from Oyvind Roa] :
        amallopt(M_FREEHD, 1, pfGetSharedArena()) ;
        amallopt(M_MXCHK, 1000L, pfGetSharedArena()) ;

...but the problem is still there.

Some other questions:
o It seems I only get half as much pfSharedArenaSize as I ask for.  If I
  pass in 1 Gig, I get a 500 meg space.  Am I missing something here?

o What is /dev/zero used for?  Using gmemusage I see that my application is
  using more and more memory for this.

Thanks for any info,
Erik

On May 21,  5:16pm, Javier Abadia Miranda wrote:
> Subject: DBASE memory leaks revisited
> Hello
>
> I am experiencing some problems with dbase management.
>
> I page in and out many pieces of a terrain dbase. And
> I notice that memory consumption is always increasing.
>
> With gmemusage I can see that what is actually getting
> bigger is Irix memory space, particulary an area called
> FS Cache.
>
> I assume that this memory area is File System cache,
> so I first thought that I had some files opened and not
> closed.
>
> I have revised my code and I am quite sure that I
> close every open file.
>
> Other "curious" effect is that if I stop moving
> during a while, the FS cache starts going down.
>
> Does Irix keep data from closed files in memory?
>
> Is there a way to prevent Irix consuming this
> phisical memory to speed up my application?
>
>
> Thank you.
>
> =======================================================================
> 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 Javier Abadia Miranda

--
____________________________________________________________________
Erik Johnson (erik.johnson@boeing.com)
The Boeing Company : Rotocraft Pilot's Associate Program
Mesa, AZ     (602) 891-7289
____________________________________________________________________



=======================================================================
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 May 21 13:28:41 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA10279 for info-performer-dist@holodeck.engr.sgi.com; Thu, 21 May 1998 13:20:11 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id NAA10252 for <info-performer@holodeck.engr.sgi.com>; Thu, 21 May 1998 13:20:10 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA31687
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 21 May 1998 13:20:09 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA29673
	for <info-performer@sgi.com>; Thu, 21 May 1998 13:20:08 -0700 (PDT)
	mail_from (kishore@aimnet.com)
Received: (from kishore@localhost)
	by aimnet.com (8.8.8/8.8.6) id NAA05425;
	Thu, 21 May 1998 13:15:43 -0700 (PDT)
Date: Thu, 21 May 1998 13:15:43 -0700 (PDT)
From: Anita Kishore <kishore@aimnet.com>
Message-Id: <199805212015.NAA05425@aimnet.com>
To: herod@evt.com, info-performer@sgi.com
Subject: Re: DBASE memory leaks revisited
Status: O

> You see this dramatic memory usage when you use the
> pfuClearTextureMemory() call (which happens when you hit the "c"
> while running 'texmem')?  That's depressing because I just adapted

Thats right. I also used pfuClearTextureMemory() call in my
actual program, but this didn't change the behavior of gmemusage.
Either there is a bug with gmemusage or I am missing something?

-anita
=======================================================================
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 May 21 13:28:44 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA10377 for info-performer-dist@holodeck.engr.sgi.com; Thu, 21 May 1998 13:27:34 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id NAA10350 for <info-performer@holodeck.engr.sgi.com>; Thu, 21 May 1998 13:27:33 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA18619
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 21 May 1998 13:27:33 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from pentagon.io.com (pentagon.io.com [199.170.88.5]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA03145
	for <info-performer@sgi.com>; Thu, 21 May 1998 13:27:31 -0700 (PDT)
	mail_from (markc@io.com)
From: markc@io.com
Received: from localhost (markc@localhost)
	by pentagon.io.com (8.8.5/8.8.5) with SMTP id PAA16989
	for <info-performer@sgi.com>; Thu, 21 May 1998 15:27:22 -0500 (CDT)
X-Authentication-Warning: pentagon.io.com: markc owned process doing -bs
Date: Thu, 21 May 1998 15:27:22 -0500 (CDT)
To: info-performer@sgi.com
Subject: pfLPointState -- continued.
Message-ID: <Pine.BSI.3.96.980521150813.2855A-100000@pentagon.io.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

Hello,

  I am still working to solve my PFLPS_INTENSITY problem,  I checked the
loader code to insure that transparency was not the problem.  It seems
that the pfLPointState cached in the geode's userdata field, was in
someway not correct.  I switched to fetching the geode's geoset, and then
geostate and finally the lpstate.

  Now PFLPS_INTENSITY seems to work, but in a global fashion, even though
each set of lights is built up from unique geoset,geostate and
pflpointstate.  All lightpoints change intensity, I'm looking at this now.

  Also, if I setval intensity to 0.0f I get a SEGV in drawX_LIGHT_POINTS.
In the file gspoint.C:644 (which of course I don't have the source to ;).

  I'm currently running 6.3 on a 02, with Performer 2.2.


Thanks
markc@io.com
markc@wesson.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 May 21 13:44:35 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA10463 for info-performer-dist@holodeck.engr.sgi.com; Thu, 21 May 1998 13:37:46 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id NAA10436 for <info-performer@holodeck.engr.sgi.com>; Thu, 21 May 1998 13:37:45 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA56471
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 21 May 1998 13:37:45 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from dataserv.dayton.sgi.com ([169.238.131.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id NAA07528
	for <info-performer@sgi.com>; Thu, 21 May 1998 13:37:43 -0700 (PDT)
	mail_from (gregl@dataserv.dayton.sgi.com)
Received: from darkwing.dayton.sgi.com by dataserv.dayton.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/930416.SGI)
	 id QAA25063; Thu, 21 May 1998 16:38:23 -0400
Received: from darkwing.dayton.sgi.com (localhost [127.0.0.1]) by darkwing.dayton.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id QAA05113; Thu, 21 May 1998 16:45:11 -0400
Sender: gregl@dataserv.dayton.sgi.com
Message-ID: <35649256.237C@dayton.sgi.com>
Date: Thu, 21 May 1998 16:45:10 -0400
From: Greg Larson <gregl@dataserv.dayton.sgi.com>
X-Mailer: Mozilla 3.04GoldC-SGI (X11; I; IRIX 6.3 IP32)
MIME-Version: 1.0
To: ericb@mitre.org
CC: Performer List <info-performer@sgi.com>
Subject: Re: 3 channel projection system
References: <13665.41431.487411.149311@pegasus>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Eric Brandwine wrote:
> 
> We have a medium fidelity cockpit simulator, and have just ordered a
> number of hardware upgrades.
> 
> We currently have an Onyx Reality Station w/MCO, driving 3 projectors
> on an ~150 degree arc.  The projectors display on 3 flat screens,
> like \_/.
> 
> We just ordered an Onyx2 IR w/DG8, 3 new projectors w/contrast
> modulation, and a single curved screen.  We want to do edge blending,
> but are not sure of a couple of things.
> 
> 1) Can the DG8 lay out channels in any geometry?  The MCO would allow
>    you to pick resolution/channel count, but you were stuck with the
>    layout they gave you (to fit in a 2kx2k virtual buffer).
> 
>    We run 3@960x680, with 3 screens tiled horizontally, while the 3
>    channels are tiled vertically.

Take a look at the ircombine utility in /usr/gfx.  This is a gui tool to
help with channel layout.  You can also do some edge blending with the
projector alignment and tuning depending on the projector.  

> 
> 2) How should we set up Performer to drive this projection system?
>    Right now, we have 3 channels defined, with the center as the
>    master, the 2 side channels offset ~50 degrees.  This means 3
>    rendering passes for our single pipeline.  Is there any way that we
>    could define a single channel with a 150 degree field of view, and
>    divide it across 3 outputs of the DG8?  Also, how should we get
>    edge blenging working?  Right now, the 3 channels that we are
>    displaying are not co-planar, so even if we were to increase the
>    horizontal field of view per channel a bit, and overlap the
>    projected images, the overlapped region would not match due to the
>    different geometries.  Is this acceptable?  Is there some way to
>    tell Performer to make some number of pixels on the edge of the
>    channel the same as the next channel over?

Ircombine will help with your channel layout and allows for an easy way
to overlap the output channels.  Ircombine is also discussed in the
Onyx2 online mannuals.

I think your observations are correct regarding distortion in trying to
draw one large field of view.  The effects of this will depend on the
curvature of your screen.  This can be traded off depending on the
accuracy/fidelity for your simulation to meet target requirements. 
There is a method used in S/W distortion correction to render a scene in
the first pass and then read back the frame buffer and map back onto a
set of polygons virtually representing your screen and sending only this
final scene to the DG. 

You may find some related demo code at www.dorbie.com  


> 
> Any help would be appreciated!
> 
> thanks,
> 
> ericb
> --
>  Eric Brandwine, Systems Engineer
>  EricB@Mitre.org
>  The MITRE Corporation, McLean VA  22102
>  (703) 883-3319   FAX: (703) 883-1917
> =======================================================================
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com

-- 
Greg Larson     (937) 258-5247	*    
Silicon Graphics/Cray Research	*The conscious mind uses 2000 neurons
Systems Engineer->VisSim Focus	*The unconscious mind, 4  Billion 
DoD High Performance Computing	*   Imagine the possibilities!!!
email: gregl@dayton.sgi.com	* 	

**********TOO CLOSE FOR MISSILES**************
**********************************************
*********    OO   H H  I   OO    *************
*********   0  0  H-H  I  0  0   *************
*********    OO   H H  I   OO    *************
*******   BIRTH PLACE OF AVIATION   **********
**                                          **
**  V   V  III  SSSS      SSSS  III  MM  MM **
**  V   V   I   S         S      I   M MM M **
**   V V    I   SSSS      SSSS   I   M MM M **
**    V     I      S         S   I   M MM M **
**    V    III  SSSS      SSSS  III  M    M **
**********************************************
**************SWITCHING TO GUNS***************
=======================================================================
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 May 21 13:48:22 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA10675 for info-performer-dist@holodeck.engr.sgi.com; Thu, 21 May 1998 13:47:37 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id NAA10648 for <info-performer@holodeck.engr.sgi.com>; Thu, 21 May 1998 13:47:35 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA62299
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 21 May 1998 13:47:35 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from lobotomy.evt.com ([204.133.157.33]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id NAA12040
	for <info-performer@sgi.com>; Thu, 21 May 1998 13:47:33 -0700 (PDT)
	mail_from (herod@evt.com)
Received: from evt.com (localhost [127.0.0.1]) by lobotomy.evt.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA06544; Thu, 21 May 1998 14:47:31 -0600
Sender: herod@evt.com
Message-ID: <356492E2.8E693170@evt.com>
Date: Thu, 21 May 1998 14:47:30 -0600
From: Scott Herod <herod@evt.com>
X-Mailer: Mozilla 4.05 [en] (X11; I; IRIX 6.3 IP32)
MIME-Version: 1.0
To: Anita Kishore <kishore@aimnet.com>, info-performer@sgi.com
Subject: Re: DBASE memory leaks revisited
References: <199805212015.NAA05425@aimnet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

I just found the memory leak in my test script.  I had adapted it
from code that I had written to check texture references and on
every loop made a call "tex->loadFile(filename)".  CVD said that
was were memory went up and when I removed the line gmemusage
stopped showing a leak.

I am glad to see that the problem looks more like that described
in other people's mail.  Now I need to figure out how to remove
the problem with loadFile().

Scott Herod

Anita Kishore wrote:
> 
> > You see this dramatic memory usage when you use the
> > pfuClearTextureMemory() call (which happens when you hit the "c"
> > while running 'texmem')?  That's depressing because I just adapted
> 
> Thats right. I also used pfuClearTextureMemory() call in my
> actual program, but this didn't change the behavior of gmemusage.
> Either there is a bug with gmemusage or I am missing something?
> 
> -anita
=======================================================================
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 May 21 15:16:24 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA11384 for info-performer-dist@holodeck.engr.sgi.com; Thu, 21 May 1998 15:15:05 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id PAA11357 for <info-performer@holodeck.engr.sgi.com>; Thu, 21 May 1998 15:15:04 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id PAA96241
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 21 May 1998 15:15:03 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA19645; Thu, 21 May 1998 15:14:56 -0700 (PDT)
	mail_from (cjackson@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 RAA01172;
	Thu, 21 May 1998 17:14:55 -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 RAA01165;
	Thu, 21 May 1998 17:14:53 -0500 (CDT)
Received: by chagos (940816.SGI.8.6.9/940406.SGI.AUTO)
	 id RAA05937; Thu, 21 May 1998 17:14:52 -0500
Date: Thu, 21 May 1998 17:14:48 +36000
From: Chris Jackson <cjackson@arlut.utexas.edu>
To: Angus Dorbie <dorbie@sgi.com>
cc: info-performer@sgi.com
Subject: Re: Going big and stereo
In-Reply-To: <35647F1B.58992EA7@sgi.com>
Message-ID: <Pine.SGI.3.90.980521164713.5838B-100000@chagos>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O



On Thu, 21 May 1998, Angus Dorbie wrote:

> 
> Configure your managed area download ot eeprom, restart graphics and use
> findvis or glxinfo to list supported visuals.

Yes, this is where I am hitting a wall.  If I restart the graphics with 
1900x1200 downloaded to eeprom, the list of available stereo visuals is 
very slim.  I get basically two visuals with stereo, and neither have 
doublebuffers.  This is to be expected, though, since I am confined to 
a "tiny" pixel depth at 1900x1200.

Without the appropriate visuals, I am resigned to implementing full 
screen stereo.  The problem is, not even STR_BOT or STR_RECT seem to be 
giving me stereo buffers.

> 
> If you can configure a managed area that size yes, but you would have to
> compile
> a video format and then all you've done is half the vertical resolution
> in each
> field so you've actually only got 1900x600 with old style stereo, (munus
> any
> blanking lines between fields)

Am I correct in thinking that this vfo would be for a
STR_RECT flavor?  In this format I draw both to the top 
half and the bottom half of the screen, and the images are superimposed 
when I call setmon.


> > 
> > At this point, I'm willing to use any resolution and any video field
> > rate...
> 
> But what about your display, you started by saying that your display
> must
> be configured to 1900x1200.
> 

Yes, this is root of the problem.  But, what I am planning on doing is 
implementing a stereo toggle option.  So my application will initially 
run with the 1900x1200 display. Should stereo be switched on, I'll 
switch to an appropriate video format and run the stereo image full 
screen.

But that is later down the road, at this point I would be happy getting 
any kind of stereo running given that the managed aread must be 
1900x1200.

Actually, I've got stereo applications for quad-buffered stereo and 
top/bottom stereo in GL, OpenGl, and Performer.  They all work great if 
I start the X server with a defualt of 1280x1024.  But as soon as I 
gfxstop and gfxstart with 1900x1200 saved to eeprom, none of my stereo 
examples work.

Is old style STR_RECT a viable option, given my hardware restraints 
and the excessive managed area?  


Thanks for all the insight and great advice...


Chris Jackson
Applied Research Laboratories - University of Texas at Austin

=======================================================================
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 May 21 15:11:02 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA11326 for info-performer-dist@holodeck.engr.sgi.com; Thu, 21 May 1998 15:04:35 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id PAA11299 for <info-performer@holodeck.engr.sgi.com>; Thu, 21 May 1998 15:04:34 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id PAA13423
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 21 May 1998 15:04:34 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA15631
	for <info-performer@sgi.com>; Thu, 21 May 1998 15:04: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 (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id PAA85539;
	Thu, 21 May 1998 15:04:32 -0700 (PDT)
	mail_from (dorbie@sgi.com)
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 PAA09802; Thu, 21 May 1998 15:04:31 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <3564A4EF.266D55FC@sgi.com>
Date: Thu, 21 May 1998 15:04: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: Greg Larson <gregl@dataserv.dayton.sgi.com>
CC: ericb@mitre.org, Performer List <info-performer@sgi.com>
Subject: Re: 3 channel projection system
References: <13665.41431.487411.149311@pegasus> <35649256.237C@dayton.sgi.com>
Content-Type: multipart/mixed; boundary="------------DCCEFE5EB5618FE0389E01FC"
Status: O

This is a multi-part message in MIME format.
--------------DCCEFE5EB5618FE0389E01FC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Greg Larson wrote:
> 
> Eric Brandwine wrote:
> >
> > We have a medium fidelity cockpit simulator, and have just ordered a
> > number of hardware upgrades.
> >
> > We currently have an Onyx Reality Station w/MCO, driving 3 projectors
> > on an ~150 degree arc.  The projectors display on 3 flat screens,
> > like \_/.
> >
> > We just ordered an Onyx2 IR w/DG8, 3 new projectors w/contrast
> > modulation, and a single curved screen.  We want to do edge blending,
> > but are not sure of a couple of things.
> >
> > 1) Can the DG8 lay out channels in any geometry?  The MCO would allow
> >    you to pick resolution/channel count, but you were stuck with the
> >    layout they gave you (to fit in a 2kx2k virtual buffer).
> >
> >    We run 3@960x680, with 3 screens tiled horizontally, while the 3
> >    channels are tiled vertically.
> 
> Take a look at the ircombine utility in /usr/gfx.  This is a gui tool to
> help with channel layout.  You can also do some edge blending with the
> projector alignment and tuning depending on the projector.
> 
> >
> > 2) How should we set up Performer to drive this projection system?
> >    Right now, we have 3 channels defined, with the center as the
> >    master, the 2 side channels offset ~50 degrees.  This means 3
> >    rendering passes for our single pipeline.  Is there any way that we
> >    could define a single channel with a 150 degree field of view, and
> >    divide it across 3 outputs of the DG8?  Also, how should we get
> >    edge blenging working?  Right now, the 3 channels that we are
> >    displaying are not co-planar, so even if we were to increase the
> >    horizontal field of view per channel a bit, and overlap the
> >    projected images, the overlapped region would not match due to the
> >    different geometries.  Is this acceptable?  Is there some way to
> >    tell Performer to make some number of pixels on the edge of the
> >    channel the same as the next channel over?
> 
> Ircombine will help with your channel layout and allows for an easy way
> to overlap the output channels.  Ircombine is also discussed in the
> Onyx2 online mannuals.

For this type of config (symmetrically rotated projectors) you can't
overlap the video channels in ircombine and make the projection work.

Your video config should do what it does now (array the video
horizontally or vertically, it doesn't matter,  but your pfChannels
should include the FOV for the full channel and the heading offset
(pre viewing rotation about Z) should match the angle between
projector headings. The offset should therefore be less than the
FOV to provide the right overlap in the video images at the
expense of a little redundant rendering.

You then do something like draw a 3D test pattern to match the screen
and align the channels on the display surface.

You should be able to drive 3@1280x1024_60 from the DG5-8 in your
ONYX2 iR if you have 2 Raster Managers. If you only have one
RM your managed area will be limited to 2*1280x1024 or equivalent
so you'll have to go with a smaller video resolution or build a
.cmb file with DVR resize built in.

I've attached some C OpenGL code to render a test pattern for
the above alignment procedure. It assumes a managed area of
3840*1024 and horizontally arrayed video channels or 1280x1024.
with left to right video matching left to right channel alignment.
Adjust the field of view & resolution settings and the heading
offset rotation for your display file and managed area size.

Note any cylindricalor spherical screen section with horizontal
top & base will lose pixels in the top and bottom center of each
channel when correctly aligned.

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/
--------------DCCEFE5EB5618FE0389E01FC
Content-Type: text/plain; charset=us-ascii; name="multifrust.c"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="multifrust.c"

/*
 * Copyright (c) 1998 Silicon Graphics, All rights Reserved.
 * multifrust.c
 *
 * To compile:
 *    cc -o multifrust -O2 -n32 -mips3 multifrust.c -lGL -lX11 -lm
 */

#include <stdlib.h>
#include <stdarg.h>
#include <unistd.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/param.h>
#include <sys/time.h>
#include <time.h>
#include <ctype.h>
#include <string.h>
#include <GL/glx.h>
#include <GL/glu.h>
#include <math.h>

#define WIN_SIZEX	(1280*3)	/* maximum window width/height */
#define WIN_SIZEY	1024		/* maximum window width/height */

#define DEGTORAD (M_PI/180.0f)

Display *display;		/* connection to X server */
XVisualInfo *vi;		/* window visual */
Window window;			/* window for drawing */
GLXContext context;		/* graphics context */


int RGBattributes[] = {
    GLX_RGBA,
    GLX_RED_SIZE, 8,
    GLX_GREEN_SIZE, 8,
    GLX_BLUE_SIZE, 8,
    None
};

/*
 * wait_for_map_notify
 *
 * Callback for XIfEvent.
 */

int
wait_for_map_notify(Display *display, XEvent *event, char *arg)
{
    return(event->type == MapNotify && event->xmap.window == (Window)arg);
}

/*
 * open_window
 *
 * Create an X window.
 */

void
open_window(void)
{
    XSetWindowAttributes swa;
    XSizeHints hints;
    XEvent event;
    XVisualInfo template;
    int c, x, y;

    display = XOpenDisplay(0);
    if (display == NULL) {
	fprintf(stderr, "Can't connect to display \"%s\"\n",
		getenv("DISPLAY"));
	exit(1);
    }
    vi = glXChooseVisual(display, DefaultScreen(display),
			 RGBattributes);
    if (vi == NULL) {
        fprintf(stderr, "can't find appropriate visual\n");
        exit(1);
    }
    swa.border_pixel = 0;
    swa.override_redirect = 1;
    swa.colormap = XCreateColormap(display, RootWindow(display, vi->screen),
				   vi->visual, AllocNone);
    swa.event_mask = ExposureMask | StructureNotifyMask | KeyPressMask;
    x = (DisplayWidth(display, vi->screen) - WIN_SIZEX) / 2;
    y = (DisplayHeight(display, vi->screen) - WIN_SIZEY) / 2;
    window = XCreateWindow(display, RootWindow(display, vi->screen),
			   x, y, WIN_SIZEX, WIN_SIZEY,
			   0, vi->depth, InputOutput, vi->visual,
			   CWBorderPixel | CWColormap | CWEventMask
			   | CWOverrideRedirect, &swa);
    if (window == 0) {
	fprintf(stderr, "could not create a window\n");
	exit(1);
    }
    XStoreName(display, window, "Perspective Quad Warp");
    hints.x = x;
    hints.y = y;
    hints.width = WIN_SIZEX;
    hints.height = WIN_SIZEY;
    hints.flags = USPosition | PSize;
    XSetNormalHints(display, window, &hints);
    XMapWindow(display, window);
    XIfEvent(display, &event, wait_for_map_notify, (char *)window);
    context = glXCreateContext(display, vi, 0, GL_TRUE);
    glXMakeCurrent(display, window, context);
}

void
draw_test_pat(void)
{
  float angle;
  int i, elevation;
  GLubyte *texdata;

  /* draw azimuth lines */
  glBegin(GL_LINES);
    for(angle = 0.0f, i=0; angle < M_PI*2; angle += DEGTORAD, i++)
    {
      if(!(i%10))
        glColor3f(1.0f, 1.0f, 1.0f);
      else
      {
        if(!(i%5))
          glColor3f(0.5f, 0.5f, 0.5f);
        else
          glColor3f(0.25f, 0.25f, 0.25f);
      }
      glVertex3f(sinf(angle)*10.0f, -100.0, cosf(angle)*10.0f);
      glVertex3f(sinf(angle)*10.0f, 100.0, cosf(angle)*10.0f);
    }
  glEnd();

  /* draw elevation lines */
  for(elevation = -88; elevation < 89; elevation++)
  {
    glBegin(GL_LINE_LOOP);
      for(angle = 0.0f; angle < M_PI*2; angle += DEGTORAD)
      {
        if(!(elevation%10))
          glColor3f(1.0f, 1.0f, 1.0f);
        else
        {
          if(!(elevation%5))
            glColor3f(0.5f, 0.5f, 0.5f);
          else
            glColor3f(0.25f, 0.25f, 0.25f);
        }
        glVertex3f(sinf(angle)*10.0f, tanf(DEGTORAD*(float)elevation)*10.0f, cosf(angle)*10.0f);
      }
    glEnd();
  }

  /* draw markers */
  glColor3f(1.0f, 1.0f, 1.0f);
  glPushMatrix();
  for(i=0; i<18; i++)
  {
    glRotatef(20.0f, 0.0f, 1.0f, 0.0f);
    glBegin(GL_LINES);
      glVertex3f(0.1f, 0.1f, 10.0f);
      glVertex3f(0.2f, 0.2f, 10.0f);
      glVertex3f(-0.1f,-0.1f, 10.0f);
      glVertex3f(-0.2f, -0.2f, 10.0f);
      glVertex3f(0.1f,-0.1f, 10.0f);
      glVertex3f(0.2f, -0.2f, 10.0f);
      glVertex3f(-0.1f,0.1f, 10.0f);
      glVertex3f(-0.2f, 0.2f, 10.0f);
    glEnd();
  }
  glPopMatrix();

  glPushMatrix();
  glRotatef(10.0f, 0.0f, 1.0f, 0.0f);
  for(i=0; i<18; i++)
  {
    glRotatef(20.0f, 0.0f, 1.0f, 0.0f);
    glBegin(GL_LINES);
      glVertex3f(0.1f, 0.2f, 10.0f);
      glVertex3f(0.2f, 0.1f, 10.0f);
      glVertex3f(-0.1f, 0.2f, 10.0f);
      glVertex3f(-0.2f, 0.1f, 10.0f);
      glVertex3f(-0.1f, -0.2f, 10.0f);
      glVertex3f(-0.2f, -0.1f, 10.0f);
      glVertex3f(0.1f, -0.2f, 10.0f);
      glVertex3f(0.2f, -0.1f, 10.0f);
    glEnd();
  }
  glPopMatrix();
}

/*
float hfov = 48.0f;
float vfov = 41.0f;
float hoff = 36.0f;
*/

float hfov = 58.0f;
float vfov = 44.0f;
float hoff = 50.0f;

void
main(int argc, char **argv)
{
    open_window();

    glMatrixMode(GL_PROJECTION);
    glLoadIdentity();
    glFrustum(-tanf(DEGTORAD*hfov/2), tanf(DEGTORAD*hfov/2), -tanf(DEGTORAD*vfov/2), tanf(DEGTORAD*vfov/2), 1.0, 1000.0);
    glMatrixMode(GL_MODELVIEW);

    glDrawBuffer(GL_FRONT);
    glClearColor(0.0f, 0.0f, 0.0f, 1.0f);
    glClear(GL_COLOR_BUFFER_BIT);
    glEnable(GL_LINE_SMOOTH);
    glHint(GL_LINE_SMOOTH_HINT, GL_NICEST);
    glEnable(GL_BLEND);
    glBlendFunc(GL_SRC_ALPHA, GL_ONE);
    
    glViewport(0, 0, WIN_SIZEX/3.0f, WIN_SIZEY);
    glLoadIdentity();
    glRotatef(-hoff, 0.0f, 1.0f, 0.0f);
    draw_test_pat();

    glViewport(WIN_SIZEX/3.0f, 0, WIN_SIZEX/3.0f, WIN_SIZEY);
    glLoadIdentity();
    draw_test_pat();

    glViewport(2.0f * WIN_SIZEX/3.0f, 0, WIN_SIZEX/3.0f, WIN_SIZEY);
    glLoadIdentity();
    glRotatef(hoff, 0.0f, 1.0f, 0.0f);
    draw_test_pat();

    glFinish();
    while(1);
}

--------------DCCEFE5EB5618FE0389E01FC--

=======================================================================
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 May 21 16:12:51 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA11811 for info-performer-dist@holodeck.engr.sgi.com; Thu, 21 May 1998 16:01:12 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id QAA11784 for <info-performer@holodeck.engr.sgi.com>; Thu, 21 May 1998 16:01:11 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id QAA04570
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 21 May 1998 16:01:10 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA06602
	for <info-performer@sgi.com>; Thu, 21 May 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 <K04W542R>; Thu, 21 May 1998 17:01:07 -0600
Message-ID: <214A87629D4FD111931F0060972989BA240707@VISTA.TACCSF.KIRTLAND.AF.MIL>
From: "Sorroche, Joe CEI-TACCSF" <Sorroche@TACCSF.KIRTLAND.AF.MIL>
To: info-performer@sgi.com
Subject: Pf warnings
Date: Thu, 21 May 1998 17:01:01 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: multipart/alternative;
	boundary="---- =_NextPart_001_01BD850C.5657AC80"
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_01BD850C.5657AC80
Content-Type: text/plain

Pfpeople;

	We have upgraded from Performer 2.0 to 2.2, and from IRIX 5.3 to
6.2. Our version of perfly seems to run ok, but we get the following
warning:

PF Debug/Resourse:  pfVideoChannel::pr_UpdateChanInfo() - screen is
still unknown - can't get info.

It scrolls by repeating the same warning.  Any Hints?

Joe

------ =_NextPart_001_01BD850C.5657AC80
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>Pf warnings</TITLE>
</HEAD>
<BODY>

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

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">We have upgraded from Performer 2.0 to 2.2, and from =
IRIX 5.3 to 6.2. Our version of perfly seems to run ok, but we get the =
following warning:</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">PF Debug/Resourse:&nbsp; =
pfVideoChannel::pr_UpdateChanInfo() - screen is still unknown - can't =
get info.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">It scrolls by repeating the same =
warning.&nbsp; Any Hints?</FONT>
</P>

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

</BODY>
</HTML>
------ =_NextPart_001_01BD850C.5657AC80--
=======================================================================
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 May 21 17:14:55 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id RAA12119 for info-performer-dist@holodeck.engr.sgi.com; Thu, 21 May 1998 17:04:01 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id RAA12092 for <info-performer@holodeck.engr.sgi.com>; Thu, 21 May 1998 17:04:00 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id RAA62405
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 21 May 1998 17:03:59 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id RAA28961
	for <info-performer@sgi.com>; Thu, 21 May 1998 17:03:59 -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 (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id RAA73948;
	Thu, 21 May 1998 17:03:58 -0700 (PDT)
	mail_from (dorbie@sgi.com)
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 RAA10141; Thu, 21 May 1998 17:03:56 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <3564C0EC.3D3A62AE@sgi.com>
Date: Thu, 21 May 1998 17:03:56 -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 Jackson <cjackson@arlut.utexas.edu>
CC: info-performer@sgi.com
Subject: Re: Going big and stereo
References: <Pine.SGI.3.90.980521164713.5838B-100000@chagos>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Chris Jackson wrote:
> 
> On Thu, 21 May 1998, Angus Dorbie wrote:
> 
> >
> > Configure your managed area download ot eeprom, restart graphics and use
> > findvis or glxinfo to list supported visuals.
> 
> Yes, this is where I am hitting a wall.  If I restart the graphics with
> 1900x1200 downloaded to eeprom, the list of available stereo visuals is
> very slim.  I get basically two visuals with stereo, and neither have
> doublebuffers.  This is to be expected, though, since I am confined to
> a "tiny" pixel depth at 1900x1200.
> 
> Without the appropriate visuals, I am resigned to implementing full
> screen stereo.  The problem is, not even STR_BOT or STR_RECT seem to be
> giving me stereo buffers.
> 
> >
> > If you can configure a managed area that size yes, but you would have to
> > compile
> > a video format and then all you've done is half the vertical resolution
> > in each
> > field so you've actually only got 1900x600 with old style stereo, (munus
> > any
> > blanking lines between fields)
> 
> Am I correct in thinking that this vfo would be for a
> STR_RECT flavor?  In this format I draw both to the top
> half and the bottom half of the screen, and the images are superimposed
> when I call setmon.

Yes, but look at your options, each field would have half the vertical
resolution, ie half the lines. You might as well half the vertical
resolution
of the managed area and get deeper pixels for use in a double buffered
modern
stereo in a window vof.

> 
> > >
> > > At this point, I'm willing to use any resolution and any video field
> > > rate...
> >
> > But what about your display, you started by saying that your display
> > must
> > be configured to 1900x1200.
> >
> 
> Yes, this is root of the problem.  But, what I am planning on doing is
> implementing a stereo toggle option.  So my application will initially
> run with the 1900x1200 display. Should stereo be switched on, I'll
> switch to an appropriate video format and run the stereo image full
> screen.
> 
> But that is later down the road, at this point I would be happy getting
> any kind of stereo running given that the managed aread must be
> 1900x1200.
> 
> Actually, I've got stereo applications for quad-buffered stereo and
> top/bottom stereo in GL, OpenGl, and Performer.  They all work great if
> I start the X server with a defualt of 1280x1024.  But as soon as I
> gfxstop and gfxstart with 1900x1200 saved to eeprom, none of my stereo
> examples work.
> 
> Is old style STR_RECT a viable option, given my hardware restraints
> and the excessive managed area?
> 
> Thanks for all the insight and great advice...
> 
> Chris Jackson
> Applied Research Laboratories - University of Texas at Austin

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 May 21 23:55:48 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id XAA13061 for info-performer-dist@holodeck.engr.sgi.com; Thu, 21 May 1998 23:45: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 XAA13034 for <info-performer@holodeck.engr.sgi.com>; Thu, 21 May 1998 23:45:08 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id XAA16785
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 21 May 1998 23:45:08 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from hni.uni-paderborn.de (hni-ff.uni-paderborn.de [131.234.22.55]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA03538
	for <info-performer@sgi.com>; Thu, 21 May 1998 23:45:03 -0700 (PDT)
	mail_from (brandt@hni.uni-paderborn.de)
Received: from hni.uni-paderborn.de (isis [131.234.176.3]) by hni.uni-paderborn.de (8.8.4/hni-mailhub) with ESMTP id IAA13379; Fri, 22 May 1998 08:43:31 +0200 (MET DST)
Message-ID: <35651E5A.2B1D428C@hni.uni-paderborn.de>
Date: Fri, 22 May 1998 08:42:34 +0200
From: Christoph Brandt <brandt@hni.uni-paderborn.de>
Organization: Heinz Nixdorf Institut
X-Mailer: Mozilla 4.03 [de] (WinNT; I)
MIME-Version: 1.0
To: SCOTT OFRIEL <ofriels1@qmsmtpgw.mugu.navy.mil>
CC: info-performer@sgi.com
Subject: Re: Purple-ish Texture
References: <n1316368245.42761@qmsmtpgw.mugu.navy.mil>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Scott,

the reason could be a faulty TRAM in your HW. We had the same effect a
while ago on an MXI system. After exchanging the TRAMs the purple-ish
textures were gone.

Hope this helps,
Christoph


SCOTT OFRIEL schrieb:
> 
> Can anyone tell me why the textures are purple-ish on my Octane?
> 
> Thank you,
> Scott
> 
> =====================================================================
> List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
>             Submissions:  info-performer@sgi.com
>         Admin. requests:  info-performer-request@sgi.com

-- 
Dipl.-Ing. Christoph Brandt     Tel. ++49 +5251 60-6233
Virtual Reality Group           Fax. ++49 +5251 60-6268
Rechnerintegrierte Produktion   http://wwwhni.uni-paderborn.de/rip
Heinz Nixdorf Institut          Fuerstenallee 11 
Universitaet GH Paderborn       D-33102 Paderborn
=======================================================================
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 May 22 06:35:07 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id GAA13696 for info-performer-dist@holodeck.engr.sgi.com; Fri, 22 May 1998 06:25:19 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id GAA13669 for <info-performer@holodeck.engr.sgi.com>; Fri, 22 May 1998 06:25:18 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id GAA28983
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 22 May 1998 06:25:17 -0700 (PDT)
	mail_from (owner-info-Performer@sgi.sgi.com)
Received: from gatekeep.marconi.ca (gatekeep.marconi.ca [198.168.197.34]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id GAA18151
	for <info-Performer@sgi.com>; Fri, 22 May 1998 06:25:07 -0700 (PDT)
	mail_from (gamblem@kan.marconi.ca)
Received: from av310a.mtl.marconi.ca by gatekeep.marconi.ca; (5.65/1.1.8.2/21Sep94-0917AM)
	id AA24460; Fri, 22 May 1998 09:24:41 -0400
Received: from kan.marconi.ca (dagwood.kan.marconi.ca)
 by av310a.mtl.marconi.ca (PMDF V5.1-8 #28207)
 with SMTP id <01IXBUYDCH3K0045SN@av310a.mtl.marconi.ca> for
 info-Performer@sgi.com; Fri, 22 May 1998 09:24:25 EDT
Received: from avgate.kan.marconi.ca by kan.marconi.ca (5.x/SMI-4.1)
 id AA19710; Fri, 22 May 1998 09:22:29 -0400
Received: by avgate.kan.marconi.ca with Microsoft Mail id
 <3565A7B8@avgate.kan.marconi.ca>; Fri, 22 May 1998 09:28:40 -0700 (PDT)
Date: Thu, 21 May 1998 17:04:00 -0700 (PDT)
From: "Gamble, Murray - Kan AV" <gamblem@kan.marconi.ca>
Subject: Re: Purple-ish Texture
To: SGI Performer Info <info-Performer@sgi.com>
Message-Id: <3565A7B8@avgate.kan.marconi.ca>
X-Mailer: Microsoft Mail V3.0
Encoding: 16 TEXT
Status: O


Hi Scott,

You may have a texture RAM problem.  We recently had a block of texture RAM 
"go bad" on our MaxImpact and this resulted in textures appearing pink and 
purple with odd looking cross-hatching patterns.

'Hope this helps.

Murray

===================================
Murray G. Gamble
Human Factors Engineering - Aerospace
Canadian Marconi Company
Kanata, Ontario, CANADA
=======================================================================
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 May 22 07:49:39 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA14083 for info-performer-dist@holodeck.engr.sgi.com; Fri, 22 May 1998 07:35:48 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id HAA14056 for <info-performer@holodeck.engr.sgi.com>; Fri, 22 May 1998 07:35:48 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA06019
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 22 May 1998 07:35:47 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id HAA08507; Fri, 22 May 1998 07:35:44 -0700 (PDT)
	mail_from (rioj7@fel.tno.nl)
Received: by dewey.fel.tno.nl; id QAA22546; Fri, 22 May 1998 16:36:04 +0200
Received: from s00sn1.fel.tno.nl(134.203.8.207) by dewey.fel.tno.nl via smap (4.1)
	id xma022082; Fri, 22 May 98 16:34:03 +0200
Received: (from rioj7@localhost)
	by s00sn1.fel.tno.nl (8.8.5/8.8.5) id QAA26351;
	Fri, 22 May 1998 16:32:47 +0200 (MET DST)
From: Mario Veraart <rioj7@fel.tno.nl>
Message-Id: <199805221432.QAA26351@s00sn1.fel.tno.nl>
Subject: Setting up drawing order (was: openGL and Performer)
To: dorbie@sgi.com (Angus Dorbie)
Date: Fri, 22 May 1998 16:32:47 +0200 (MET DST)
Cc: info-performer@sgi.com (Performer)
In-Reply-To: <35630F31.E2B4C2CA@sgi.com> from "Angus Dorbie" at May 20, 98 10:13:21 am
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Status: O

Angus Dorbie wrote:
> 
> Disable depth writes and draw first to avoid zbuffer problems.
> 

How do you set things up so geometry will be rendered in the order you
want? Is the bin mechanism the way to go, or is there an alternative?

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 May 22 10:06:15 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA14450 for info-performer-dist@holodeck.engr.sgi.com; Fri, 22 May 1998 09:50:50 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA14421 for <info-performer@holodeck.engr.sgi.com>; Fri, 22 May 1998 09:50:49 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA50507
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 22 May 1998 09:50:49 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from quid.csd.sgi.com ([150.166.129.99]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA21412
	for <info-performer@sgi.com>; Fri, 22 May 1998 09:50:47 -0700 (PDT)
	mail_from (robj@quid.csd.sgi.com)
Received: (from robj@localhost) by quid.csd.sgi.com (980205.SGI.8.8.8/960327.SGI.AUTOCF) id JAA21001; Fri, 22 May 1998 09:49:20 -0700 (PDT)
From: "Rob Jenkins" <robj@quid.csd.sgi.com>
Message-Id: <9805220949.ZM20950@quid.csd.sgi.com>
Date: Fri, 22 May 1998 09:49:19 -0700
In-Reply-To: Christoph Brandt <brandt@hni.uni-paderborn.de>
        "Re: Purple-ish Texture" (May 22,  8:42am)
References: <n1316368245.42761@qmsmtpgw.mugu.navy.mil> 
	<35651E5A.2B1D428C@hni.uni-paderborn.de>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Christoph Brandt <brandt@hni.uni-paderborn.de>,
        SCOTT OFRIEL <ofriels1@qmsmtpgw.mugu.navy.mil>
Subject: Re: Purple-ish Texture
Cc: info-performer@sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

Just an addition to this: It could be bad HW or just badly seated HW, there's
also a rare case when a single GE machine gets upgrade to a dual GE machine (
eg Hi Impact to Max Impact or low end OCTANE to MXI ), if the extra, duplicate
TRAM doesn't get added then you get this effect. I would advise caution before
messing with the TRAM boards, they're very sensitive to static and physical
damage so if you have any doubts about your HW then please log a support call.

Cheers
Rob

On May 22,  8:42am, Christoph Brandt wrote:
> Subject: Re: Purple-ish Texture
> Scott,
>
> the reason could be a faulty TRAM in your HW. We had the same effect a
> while ago on an MXI system. After exchanging the TRAMs the purple-ish
> textures were gone.
>
> Hope this helps,
> Christoph
>
>
> SCOTT OFRIEL schrieb:
> >
> > Can anyone tell me why the textures are purple-ish on my Octane?
> >
> > Thank you,
> > Scott
> >
> > =====================================================================
> > List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
> >             Submissions:  info-performer@sgi.com
> >         Admin. requests:  info-performer-request@sgi.com
>
> --
> Dipl.-Ing. Christoph Brandt     Tel. ++49 +5251 60-6233
> Virtual Reality Group           Fax. ++49 +5251 60-6268
> Rechnerintegrierte Produktion   http://wwwhni.uni-paderborn.de/rip
> Heinz Nixdorf Institut          Fuerstenallee 11
> Universitaet GH Paderborn       D-33102 Paderborn
> =======================================================================
> 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 Christoph Brandt



-- 
________________________________________________________________
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 May 22 10:36:18 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA14528 for info-performer-dist@holodeck.engr.sgi.com; Fri, 22 May 1998 10:21:42 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id KAA14501 for <info-performer@holodeck.engr.sgi.com>; Fri, 22 May 1998 10:21:42 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA62978
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 22 May 1998 10:21:41 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA05628
	for <info-performer@sgi.com>; Fri, 22 May 1998 10:21:40 -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 (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA22228;
	Fri, 22 May 1998 09:43:33 -0700 (PDT)
	mail_from (dorbie@sgi.com)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id JAA06637; Fri, 22 May 1998 09:43:32 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <3565AB34.44BB21BA@sgi.com>
Date: Fri, 22 May 1998 09:43:32 -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: Mario Veraart <rioj7@fel.tno.nl>
CC: Performer <info-performer@sgi.com>
Subject: Re: Setting up drawing order (was: openGL and Performer)
References: <199805221432.QAA26351@s00sn1.fel.tno.nl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Mario Veraart wrote:
> 
> Angus Dorbie wrote:
> >
> > Disable depth writes and draw first to avoid zbuffer problems.
> >
> 
> How do you set things up so geometry will be rendered in the order you
> want? Is the bin mechanism the way to go, or is there an alternative?
> 

Bins are the way, and there are alternatives like using other channels.

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 May 22 15:29:23 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA16735 for info-performer-dist@holodeck.engr.sgi.com; Fri, 22 May 1998 15:14:28 -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 PAA16708 for <info-performer@holodeck.engr.sgi.com>; Fri, 22 May 1998 15:14:27 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id PAA74876
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 22 May 1998 15:14:26 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA26001
	for <info-performer@sgi.com>; Fri, 22 May 1998 15:14:24 -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 <LN8MST4Q>; Fri, 22 May 1998 16:14:17 -0600
Message-ID: <214A87629D4FD111931F0060972989BA24070A@VISTA.TACCSF.KIRTLAND.AF.MIL>
From: "Sorroche, Joe CEI-TACCSF" <Sorroche@TACCSF.KIRTLAND.AF.MIL>
To: info-performer@sgi.com
Subject: SGI Interrupts
Date: Fri, 22 May 1998 16:14:16 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: multipart/alternative;
	boundary="---- =_NextPart_001_01BD85CE.F5B3DBD0"
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_01BD85CE.F5B3DBD0
Content-Type: text/plain

People;

	We're running Performer 2.2 on an Onyx, IRIX 6.2 OS.  When we
run gr_osview, for a second, the interrupts "peg" the processor.  Any
hints?

Joe

------ =_NextPart_001_01BD85CE.F5B3DBD0
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>SGI Interrupts</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">We're running Performer 2.2 on an Onyx, IRIX 6.2 =
OS.&nbsp; When we run gr_osview, for a second, the interrupts =
&quot;peg&quot; the processor.&nbsp; Any hints?</FONT></P>

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

</BODY>
</HTML>
------ =_NextPart_001_01BD85CE.F5B3DBD0--
=======================================================================
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 May 22 18:10:40 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id RAA18022 for info-performer-dist@holodeck.engr.sgi.com; Fri, 22 May 1998 17:51: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 RAA17995 for <info-performer@holodeck.engr.sgi.com>; Fri, 22 May 1998 17:51:08 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id RAA01363
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 22 May 1998 17:51:08 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id RAA08674
	for <info-performer@sgi.com>; Fri, 22 May 1998 17:51:07 -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 (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id RAA32513;
	Fri, 22 May 1998 17:51:02 -0700 (PDT)
	mail_from (dorbie@sgi.com)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id RAA02138; Fri, 22 May 1998 17:51:01 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <35661D75.5463A5E9@sgi.com>
Date: Fri, 22 May 1998 17:51:01 -0700
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5 IP22)
MIME-Version: 1.0
To: "Sorroche, Joe CEI-TACCSF" <Sorroche@TACCSF.KIRTLAND.AF.MIL>
CC: info-performer@sgi.com
Subject: Re: SGI Interrupts
References: <214A87629D4FD111931F0060972989BA24070A@VISTA.TACCSF.KIRTLAND.AF.MIL>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

> Sorroche, Joe CEI-TACCSF wrote:
> 
> People;
> 
>         We're running Performer 2.2 on an Onyx, IRIX 6.2 OS.  When we
> run gr_osview, for a second, the interrupts "peg" the processor.  Any
> hints?
> 

You need to isolate and lockdown the CPUs you need for real-time and
put a NOINTR=cpu_number directive for those CPUs in the stune file
(I think) I can't confirm this right now but there should be mention
of this in the archives and no doubt someone with a better memory than
I will post the exact details.

The new IRIX 6.5 OS has really kernel threads & interrupts so you
shouldn't have to worry about this in future unless you are _really_
running at a high frame rate (I mean kHz).

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 May 22 18:51:28 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id SAA18127 for info-performer-dist@holodeck.engr.sgi.com; Fri, 22 May 1998 18:30: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 SAA18100 for <info-performer@holodeck.engr.sgi.com>; Fri, 22 May 1998 18:30:54 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id SAA44554
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 22 May 1998 18:30:53 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA17496
	for <info-performer@sgi.com>; Fri, 22 May 1998 18:30:53 -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 (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id SAA39013;
	Fri, 22 May 1998 18:30:52 -0700 (PDT)
	mail_from (dorbie@sgi.com)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id SAA02234; Fri, 22 May 1998 18:30:51 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <356626CB.50D6EEF5@sgi.com>
Date: Fri, 22 May 1998 18:30:51 -0700
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5 IP22)
MIME-Version: 1.0
To: "Sorroche, Joe CEI-TACCSF" <Sorroche@TACCSF.KIRTLAND.AF.MIL>,
        info-performer@sgi.com
Subject: Re: SGI Interrupts
References: <214A87629D4FD111931F0060972989BA24070A@VISTA.TACCSF.KIRTLAND.AF.MIL> <35661D75.5463A5E9@sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Angus Dorbie wrote:
> 
> > Sorroche, Joe CEI-TACCSF wrote:
> >
> > People;
> >
> >         We're running Performer 2.2 on an Onyx, IRIX 6.2 OS.  When we
> > run gr_osview, for a second, the interrupts "peg" the processor.  Any
> > hints?
> >
> 
> You need to isolate and lockdown the CPUs you need for real-time and
> put a NOINTR=cpu_number directive for those CPUs in the stune file
> (I think) I can't confirm this right now but there should be mention
> of this in the archives and no doubt someone with a better memory than
> I will post the exact details.
> 
> The new IRIX 6.5 OS has really kernel threads & interrupts so you

                                ^ insert "light weight" here (must type
slower & think faster).

> shouldn't have to worry about this in future unless you are _really_
> running at a high frame rate (I mean kHz).
> 
> 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

-- 
"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 May 22 19:11:54 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id SAA18297 for info-performer-dist@holodeck.engr.sgi.com; Fri, 22 May 1998 18:48: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 SAA18270 for <info-performer@holodeck.engr.sgi.com>; Fri, 22 May 1998 18:48:43 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id SAA48039
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 22 May 1998 18:48:42 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id SAA21077; Fri, 22 May 1998 18:48:38 -0700 (PDT)
	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 VAA26048; Fri, 22 May 1998 21:48:34 -0400
Received: (from brian@localhost) by dingbat.clubfed.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA13140; Fri, 22 May 1998 21:34:31 -0400
Date: Fri, 22 May 1998 21:34:31 -0400
From: brian@dingbat.clubfed.sgi.com (Brian Furtaw)
Message-Id: <9805222134.ZM13139@dingbat.clubfed.sgi.com>
In-Reply-To: Angus Dorbie <dorbie@sgi.com>
        "Re: SGI Interrupts" (May 22,  5:51pm)
References: <214A87629D4FD111931F0060972989BA24070A@VISTA.TACCSF.KIRTLAND.AF.MIL> 
	<35661D75.5463A5E9@sgi.com>
Reply-To: brian@sgi.com
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Angus Dorbie <dorbie@sgi.com>,
        "Sorroche, Joe CEI-TACCSF" <Sorroche@taccsf.kirtland.af.mil>
Subject: Re: SGI Interrupts
Cc: info-performer@sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

The file you are refering to Angus is /var/sysgen/system/irix.sm. Simply add
the CPUs you wish to sheild from interrupts to the list after the NOINTR tag.
autoconfig -fv to rebuild the kernel and reboot.


Brian


On May 22,  5:51pm, Angus Dorbie wrote:
> Subject: Re: SGI Interrupts
> > Sorroche, Joe CEI-TACCSF wrote:
> >
> > People;
> >
> >         We're running Performer 2.2 on an Onyx, IRIX 6.2 OS.  When we
> > run gr_osview, for a second, the interrupts "peg" the processor.  Any
> > hints?
> >
>
> You need to isolate and lockdown the CPUs you need for real-time and
> put a NOINTR=cpu_number directive for those CPUs in the stune file
> (I think) I can't confirm this right now but there should be mention
> of this in the archives and no doubt someone with a better memory than
> I will post the exact details.
>
> The new IRIX 6.5 OS has really kernel threads & interrupts so you
> shouldn't have to worry about this in future unless you are _really_
> running at a high frame rate (I mean kHz).
>
> 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
>
>-- End of excerpt from Angus Dorbie



-- 
    ----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  Sat May 23 12:57:22 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id MAA19712 for info-performer-dist@holodeck.engr.sgi.com; Sat, 23 May 1998 12:39:25 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id MAA19685 for <info-performer@holodeck.engr.sgi.com>; Sat, 23 May 1998 12:39:22 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA68081
	for <info-performer@cthulhu.engr.sgi.com>;
	Sat, 23 May 1998 12:39:20 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from web4.rocketmail.com (web4.rocketmail.com [205.180.57.78]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id MAA24862
	for <info-performer@sgi.com>; Sat, 23 May 1998 12:39:19 -0700 (PDT)
	mail_from (joaquim@rocketmail.com)
Message-ID: <19980523193631.9197.rocketmail@web4.rocketmail.com>
Received: from [194.65.237.170] by web4; Sat, 23 May 1998 12:36:31 PDT
Date: Sat, 23 May 1998 12:36:31 -0700 (PDT)
From: Joaquim Muchaxo <joaquim@rocketmail.com>
Reply-To: joaquim@imersiva.ch
Subject: Drawing in pixels ?? 
To: info-performer@sgi.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

Isn't there a function in performer similar
to glDrawPixels ??

I am also trying to draw a texture on the screen at a X, Y
I was successfull to do this with a DCS, placing the
DCS in a position in front of the viewpoint. However,
when I chenge the viewp. the xy "bounces" randomly in
its position, when it stops it gets ok. I had the same
problem with pfuGetNearestVisiblePoint. 
I am using two processes, one for draw other for app_cull
Any hints ?

Thanks in advance,


===
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





_________________________________________________________
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  Sat May 23 14:41:21 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA19968 for info-performer-dist@holodeck.engr.sgi.com; Sat, 23 May 1998 14:27:19 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id OAA19941 for <info-performer@holodeck.engr.sgi.com>; Sat, 23 May 1998 14:27:18 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA90812
	for <info-performer@cthulhu.engr.sgi.com>;
	Sat, 23 May 1998 14:27:17 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA11477
	for <info-performer@sgi.com>; Sat, 23 May 1998 14:27:16 -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 (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA90315;
	Sat, 23 May 1998 14:27:16 -0700 (PDT)
	mail_from (dorbie@sgi.com)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA02629; Sat, 23 May 1998 14:27:15 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <35673F33.5915AACD@sgi.com>
Date: Sat, 23 May 1998 14:27:15 -0700
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5 IP22)
MIME-Version: 1.0
To: joaquim@imersiva.ch
CC: info-performer@sgi.com
Subject: Re: Drawing in pixels ??
References: <19980523193631.9197.rocketmail@web4.rocketmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Joaquim Muchaxo wrote:
> 
> Isn't there a function in performer similar
> to glDrawPixels ??

Yes! It's called glDrawPixels you can call the gl from
a draw callback.

> 
> I am also trying to draw a texture on the screen at a X, Y
> I was successfull to do this with a DCS, placing the
> DCS in a position in front of the viewpoint. However,
> when I chenge the viewp. the xy "bounces" randomly in
> its position, when it stops it gets ok. I had the same
> problem with pfuGetNearestVisiblePoint.

The problem is you are passing data straight through shared
memory to the draw and sync issues & viewpoint vs DCS latency
are biting you.

> I am using two processes, one for draw other for app_cull
> Any hints ?

Yes, you have two options, create and update the DCS in the
application or pfFlux the DCS position information through
to the draw instead of reading it straight from shared memory.

Either will work.

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 May 25 05:56:58 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id FAA22011 for info-performer-dist@holodeck.engr.sgi.com; Mon, 25 May 1998 05:46:48 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id FAA21984 for <info-performer@holodeck.engr.sgi.com>; Mon, 25 May 1998 05:46:46 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id FAA32563
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 25 May 1998 05:46:45 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from pc43.neurobiologie.ruhr-uni-bochum.de (pc43.neurobiologie.ruhr-uni-bochum.de [134.147.120.53]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id FAA10305
	for <info-performer@sgi.com>; Mon, 25 May 1998 05:46:41 -0700 (PDT)
	mail_from (paolini@pc43.neurobiologie.ruhr-uni-bochum.de)
Received: (from paolini@localhost)
	by pc43.neurobiologie.ruhr-uni-bochum.de (8.8.7/8.8.7) id OAA01471
	for info-performer@sgi.com; Mon, 25 May 1998 14:55:23 +0200
From: Monica Paolini <paolini@neurobiologie.ruhr-uni-bochum.de>
Message-Id: <199805251255.OAA01471@pc43.neurobiologie.ruhr-uni-bochum.de>
Subject: recurrent space model
To: info-performer@sgi.com
Date: Mon, 25 May 1998 14:55:23 +0200 (CEST)
Content-Type: text
Status: O

Hi,

I am trying to set up an application which simulates self-motion
is a very simple environment which should be able to run continuously 
-or say for a couple of hours. The background is homogeneous 3D set 
of pfLightPoints. Currently I create a large enough number of light
points in a large enough space that self-motion is possible for only for 
a few seconds without going out of the defined region. But of course 
this is not a good solution. 

I would like to be able to define a small 3D region, put my light points and
then re-present the same region whenever necessary, so that the background 
with random dots is constantly there. As long as the borders of these 
regions are seamlessly integrated I do not mind that the same random pattern 
of light points appears again and again. From what I understand, this should 
be something like texture tiling, but with a volume of space being the tile 
instead of a texture. Or maybe it is possible to construct the 3D region 
with random dots as a texture. 

I have not found any information on how to build such a recurrent model 
of space --or about other ways to solve this problem, although it seems
that should be rather common. I will very much appreciate any help 
you could give me. 
 
Monica 

______________________________________________________________________________  
Monica Paolini                        paolini@neurobiologie.ruhr-uni-bochum.de  
Allg. Zoologie und Neurobiologie	     http://phaistos.ucsd.edu/~paolini	
ND7/31   		     http://homepage.ruhr-uni-bochum.de/Monica.Paolini 
Ruhr Universitaet Bochum		             1-49-234-700-7008 (voice) 
44780 Bochum GERMANY                                   1-49-234-709-4278 (fax) 
 

=======================================================================
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 May 25 07:25:06 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA22236 for info-performer-dist@holodeck.engr.sgi.com; Mon, 25 May 1998 07:12:36 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id HAA22209 for <info-performer@holodeck.engr.sgi.com>; Mon, 25 May 1998 07:12:35 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA67627
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 25 May 1998 07:12:34 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA24606
	for <info-performer@sgi.com>; Mon, 25 May 1998 07:12:32 -0700 (PDT)
	mail_from (Jean-Luc.Douville@imag.fr)
Received: from safran.imag.fr (safran.imag.fr [129.88.42.9])
	by imag.imag.fr (8.8.5/8.8.5) with ESMTP id PAA13935;
	Mon, 25 May 1998 15:51:05 +0200 (MET DST)
Received: (from douville@localhost) by safran.imag.fr (8.6.10/8.6.9) id PAA21720; Mon, 25 May 1998 15:51:05 +0200
From: Jean-Luc Douville <Jean-Luc.Douville@imag.fr>
Message-Id: <199805251351.PAA21720@safran.imag.fr>
Subject: DSO' version ?
To: info-performer@sgi.com
Date: Mon, 25 May 1998 15:51:04 +0200 (MDT)
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Status: O

I am currently working on a Database Loader. With Performer 2.0 it was
fine running with ld -shared -set_version sgi1.0 *.o -o libpfext_ogl.so

But with PF2.2, N32, I found that I must set the version "sgi4.0.440" 
(ld -n32 -shared -set_version sgi4.0.440 *.o -o libpfext_ogl.so)

My question : how can i know the version of the currently used DSOs ?

+-------------------+------------------------------------------------------+
| Jean-Luc Douville | GRAVIR/IMAG, B.P. 53, 38041 Grenoble Cedex 9. France |
|                   | Tel: (+33) 4.76.63.55.74 -- Fax: (+33) 4.76.63.55.80 |
+-------------------+-----------------+------------------------------------+
| E-Mail: Jean-Luc.Douville@imag.fr   | W3: http://w3imagis.imag.fr/       | 
+-------------------------------------+------------------------------------+
=======================================================================
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 May 25 09:34:27 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA22686 for info-performer-dist@holodeck.engr.sgi.com; Mon, 25 May 1998 09:20:00 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA22659 for <info-performer@holodeck.engr.sgi.com>; Mon, 25 May 1998 09:19:59 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA89583
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 25 May 1998 09:19:59 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id JAA18171
	for <info-performer@sgi.com>; Mon, 25 May 1998 09:19:56 -0700 (PDT)
	mail_from (rioj7@fel.tno.nl)
Received: by dewey.fel.tno.nl; id SAA20479; Mon, 25 May 1998 18:20:06 +0200
Received: from s00sn1.fel.tno.nl(134.203.8.207) by dewey.fel.tno.nl via smap (4.1)
	id xma020472; Mon, 25 May 98 18:19:12 +0200
Received: (from rioj7@localhost)
	by s00sn1.fel.tno.nl (8.8.5/8.8.5) id SAA09213;
	Mon, 25 May 1998 18:17:54 +0200 (MET DST)
From: Mario Veraart <rioj7@fel.tno.nl>
Message-Id: <199805251617.SAA09213@s00sn1.fel.tno.nl>
Subject: Re: DSO' version ?
To: Jean-Luc.Douville@imag.fr (Jean-Luc Douville)
Date: Mon, 25 May 1998 18:17:54 +0200 (MET DST)
Cc: info-performer@sgi.com
In-Reply-To: <199805251351.PAA21720@safran.imag.fr> from "Jean-Luc Douville" at May 25, 98 03:51:04 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Status: O

> I am currently working on a Database Loader. With Performer 2.0 it was
> fine running with ld -shared -set_version sgi1.0 *.o -o libpfext_ogl.so
> 
> But with PF2.2, N32, I found that I must set the version "sgi4.0.440" 
> (ld -n32 -shared -set_version sgi4.0.440 *.o -o libpfext_ogl.so)
> 
> My question : how can i know the version of the currently used DSOs ?

Use:

elfdump -L <libname> | grep IVERSION

Mario
> 
> +-------------------+------------------------------------------------------+
> | Jean-Luc Douville | GRAVIR/IMAG, B.P. 53, 38041 Grenoble Cedex 9. France |
> |                   | Tel: (+33) 4.76.63.55.74 -- Fax: (+33) 4.76.63.55.80 |
> +-------------------+-----------------+------------------------------------+
> | E-Mail: Jean-Luc.Douville@imag.fr   | W3: http://w3imagis.imag.fr/       | 
> +-------------------------------------+------------------------------------+
> =======================================================================
> 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 May 25 09:34:24 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA22717 for info-performer-dist@holodeck.engr.sgi.com; Mon, 25 May 1998 09:20:35 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA22690 for <info-performer@holodeck.engr.sgi.com>; Mon, 25 May 1998 09:20:34 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA87091
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 25 May 1998 09:20:33 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id JAA18317
	for <info-performer@sgi.com>; Mon, 25 May 1998 09:20:30 -0700 (PDT)
	mail_from (rioj7@fel.tno.nl)
Received: by dewey.fel.tno.nl; id SAA20436; Mon, 25 May 1998 18:14:03 +0200
Received: from s00sn1.fel.tno.nl(134.203.8.207) by dewey.fel.tno.nl via smap (4.1)
	id xma020420; Mon, 25 May 98 18:13:37 +0200
Received: (from rioj7@localhost)
	by s00sn1.fel.tno.nl (8.8.5/8.8.5) id SAA09122;
	Mon, 25 May 1998 18:12:20 +0200 (MET DST)
From: Mario Veraart <rioj7@fel.tno.nl>
Message-Id: <199805251612.SAA09122@s00sn1.fel.tno.nl>
Subject: Re: recurrent space model
To: paolini@neurobiologie.ruhr-uni-bochum.de (Monica Paolini)
Date: Mon, 25 May 1998 18:12:20 +0200 (MET DST)
Cc: info-performer@sgi.com
In-Reply-To: <199805251255.OAA01471@pc43.neurobiologie.ruhr-uni-bochum.de> from "Monica Paolini" at May 25, 98 02:55:23 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Status: O

Monica Paolini wrote:
> 
> I am trying to set up an application which simulates self-motion
> is a very simple environment which should be able to run continuously 
> -or say for a couple of hours. The background is homogeneous 3D set 
> of pfLightPoints. Currently I create a large enough number of light
> points in a large enough space that self-motion is possible for only for 
> a few seconds without going out of the defined region. But of course 
> this is not a good solution. 
> 
> I would like to be able to define a small 3D region, put my light points and
> then re-present the same region whenever necessary, so that the background 
> with random dots is constantly there. As long as the borders of these 

(Tip of Angus Dorby)
If you want to achieve the effect of stars in the sky you can put the
'stars' geometry below a pfDCS and let it move with the viewer.
xyz of DCS == xyz of viewer, hpr of DCS == 0,0,0.

> regions are seamlessly integrated I do not mind that the same random pattern 
> of light points appears again and again. From what I understand, this should 
> be something like texture tiling, but with a volume of space being the tile 
> instead of a texture. Or maybe it is possible to construct the 3D region 
> with random dots as a texture. 

If on the other hand you want to have the effect of flying trough the
light points (Star Trek Warp) you can just repeat a random placement
of points below a couple of DCS nodes that each belong to a different
type of tile. 

> I have not found any information on how to build such a recurrent model 
> of space --or about other ways to solve this problem, although it seems
> that should be rather common. I will very much appreciate any help 
> you could give me. 

If you have a very large region of space filled with tiles you better
move the terrain tiles in stead of moving the viewpoint. And keep
track of the tile and view positions in a double and convert the
difference to a float and use that as the translation component of the
pfDCS that is positioning the tile in the scene.
In the archives there is complete description of this algorithm.

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 May 25 14:34:07 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA23600 for info-performer-dist@holodeck.engr.sgi.com; Mon, 25 May 1998 14:28:21 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id OAA23573 for <info-performer@holodeck.engr.sgi.com>; Mon, 25 May 1998 14:28:20 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA70517
	for <info-performer@cthulhu.engr.sgi.com>;
	Mon, 25 May 1998 14:28:19 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id OAA17647
	for <info-performer@sgi.com>; Mon, 25 May 1998 14:28:18 -0700 (PDT)
	mail_from (rioj7@fel.tno.nl)
Received: by dewey.fel.tno.nl; id XAA27464; Mon, 25 May 1998 23:28:37 +0200
Received: from s00sn1.fel.tno.nl(134.203.8.207) by dewey.fel.tno.nl via smap (4.1)
	id xma027460; Mon, 25 May 98 23:28:17 +0200
Received: (from rioj7@localhost)
	by s00sn1.fel.tno.nl (8.8.5/8.8.5) id XAA13707;
	Mon, 25 May 1998 23:26:59 +0200 (MET DST)
From: Mario Veraart <rioj7@fel.tno.nl>
Message-Id: <199805252126.XAA13707@s00sn1.fel.tno.nl>
Subject: Using bins to draw in Performer 2.2
To: info-performer@sgi.com (Performer)
Date: Mon, 25 May 1998 23:26:59 +0200 (MET DST)
Cc: rioj7@s00sn1.fel.tno.nl (Mario Veraart)
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Status: O

Hi pfAll,

I have tried to use bins to draw the geometry in the order I want.
For this I replaced the call to pfDraw() with

    pfDrawBin(PFSORT_OPAQUE_BIN);
    pfDrawBin(PFSORT_TRANSP_BIN);

The scene consists of a few cubes. Some of them are transparent others
are opaque. Every geoset has a geostate and the bins are explicitly
set to the opaque bin or transparent bin.

When I use pfDraw I see the complete scene. When using the two calls
to replace pfDraw I only see the cubes that are transparent.
if I add the call

    pfDrawBin(-1);

The opaque geometry is drawn as wanted.
The channel traversal mode is the default, so it should contain
PFCULL_SORT.

Is this the normal behaviour?

When I add two bins to the channel and put my geometry in them and
call pfDrawBin() with these two numbers the geometry is drawn ok.
I don't need to call  pfDrawBin(-1).

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  Tue May 26 08:32:42 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id IAA24754 for info-performer-dist@holodeck.engr.sgi.com; Tue, 26 May 1998 08:24:53 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id IAA24727 for <info-performer@holodeck.engr.sgi.com>; Tue, 26 May 1998 08:24:48 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id IAA63727
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 26 May 1998 08:24:43 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA19901
	for <info-performer@sgi.com>; Tue, 26 May 1998 08:24:40 -0700 (PDT)
	mail_from (sbaker@link.com)
Received: from borgus.bgm.link.com (borgus.bgm.link.com [130.210.236.13])
          by lfkw10.bgm.link.com (8.8.6/HTI-Hack-8.8.4) with SMTP
	  id KAA06743; Tue, 26 May 1998 10:16:58 -0500 (CDT)
Date: Tue, 26 May 1998 10:16:06 -0500 (CDT)
From: Steve Baker <sbaker@link.com>
X-Sender: steve@borgus.bgm.link.com
Reply-To: Steve Baker <sbaker@link.com>
To: Monica Paolini <paolini@neurobiologie.ruhr-uni-bochum.de>
cc: info-performer@sgi.com
Subject: Re: recurrent space model
In-Reply-To: <199805251255.OAA01471@pc43.neurobiologie.ruhr-uni-bochum.de>
Message-ID: <Pine.SGI.3.96.980526101128.2487B-100000@borgus.bgm.link.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

On Mon, 25 May 1998, Monica Paolini wrote:

> I am trying to set up an application which simulates self-motion
> is a very simple environment which should be able to run continuously 
> -or say for a couple of hours. The background is homogeneous 3D set 
> of pfLightPoints. Currently I create a large enough number of light
> points in a large enough space that self-motion is possible for only for 
> a few seconds without going out of the defined region. But of course 
> this is not a good solution. 
> 
> I would like to be able to define a small 3D region, put my light points and
> then re-present the same region whenever necessary, so that the background 
> with random dots is constantly there. As long as the borders of these 
> regions are seamlessly integrated I do not mind that the same random pattern 
> of light points appears again and again. From what I understand, this should 
> be something like texture tiling, but with a volume of space being the tile 
> instead of a texture. Or maybe it is possible to construct the 3D region 
> with random dots as a texture. 

For this application, it might be easier for you to move the eyepoint
than the model.

Why not build a 3x3 (or maybe 5x5) grid of identical light point sets,
with the origin at the center. For the sake of this explanation, suppose
the grid is 100 feet per repeat of the model.

Whenever the eyepoint has moved more than 100 feet in either the X or
Y axis, 'teleport' it back 100 feet towards the origin. Since the
pattern of lights around the origin is identical to that 100 feet
away, the 'teleport' shouldn't produce a noticable effect - except on
the lights in the very far distance.

This is functionally very similar to moving the tiles of the model
around (as pfDCS's presumably) - but has the advantage that even
after hours of motion, your eyepoint coordinates are close to zero,
so you don't get numerical roundoff problems.

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 May 26 13:56:35 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA25898 for info-performer-dist@holodeck.engr.sgi.com; Tue, 26 May 1998 13:48:22 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id NAA25871 for <info-performer@holodeck.engr.sgi.com>; Tue, 26 May 1998 13:48:21 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA40263
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 26 May 1998 13:48:20 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from pentagon.io.com (pentagon.io.com [199.170.88.5]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA08752
	for <info-performer@sgi.com>; Tue, 26 May 1998 13:48:19 -0700 (PDT)
	mail_from (markc@io.com)
From: markc@io.com
Received: from localhost (markc@localhost)
	by pentagon.io.com (8.8.5/8.8.5) with SMTP id PAA03484
	for <info-performer@sgi.com>; Tue, 26 May 1998 15:48:18 -0500 (CDT)
X-Authentication-Warning: pentagon.io.com: markc owned process doing -bs
Date: Tue, 26 May 1998 15:48:17 -0500 (CDT)
To: info-performer@sgi.com
Subject: pfLPointState -- again.
Message-ID: <Pine.BSI.3.96.980526143008.28793A-100000@pentagon.io.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

Hello,

  I am still working out exactly what is going on with my light points, I
am still having troubles adjusting the PFLPS_INTENSITY of just one set of
lights.  Every runway has its lights in a geoset, with its own geostate,
and lpstate.  When I adjust the intensity of one, the others also are
modified.  This what I can say for certain is as follows:

  1.)  In the loader, I printf the addresses of the geoset,geostate, and
lpointstate.  After attaching the geoset and geostate to the geode, I get
the addresses back from the geode, with pfGetGSet, pfGetGSetGState, and
pfGetGStateAttr(gs,PFSTATE_ENLIGHTPOINTSTATE).  They match the locals,
and are unique to each runway.

  2.)  Back in the APP I use pfdStoreFile, and write a ".out" ascii
version of my scene, the geoset and geostate addresses match my printf's
from the loader.  But the lpointstates do not!  The ascii dump shows, that
the first lpstate is set correctly, but all geostates after this show the
lpointstate address as that of the first one created, not inherited.


  Is there some state optimization causing this ?  Really irritating,
maybe its time for a problem report... sigh...


thanks

markc@io.com
markc@wesson.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 May 26 14:27:38 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA26348 for info-performer-dist@holodeck.engr.sgi.com; Tue, 26 May 1998 14:17:12 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id OAA26321 for <info-performer@holodeck.engr.sgi.com>; Tue, 26 May 1998 14:17:06 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA59393
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 26 May 1998 14:17:05 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from PO-Box-307.ridgefield.sdr.slb.com (po-box-307.ridgefield.sdr.slb.com [163.185.59.1]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id OAA21561
	for <info-performer@sgi.com>; Tue, 26 May 1998 14:16:47 -0700 (PDT)
	mail_from (andrews@ridgefield.sdr.slb.com)
Received: from samoyed (samoyed [163.185.56.57]) by PO-Box-307.ridgefield.sdr.slb.com (8.6.12/8.6.12) with SMTP id RAA18542 for <info-performer@sgi.com>; Tue, 26 May 1998 17:16:32 -0400
Sender: andrews@ridgefield.sdr.slb.com
Message-ID: <356B312F.2781@ridgefield.sdr.slb.com>
Date: Tue, 26 May 1998 17:16:31 -0400
From: "Ballard Andrews; (4/28/98)" <andrews@ridgefield.sdr.slb.com>
Organization: Schlumberger-Doll Research
X-Mailer: Mozilla 2.01S (X11; I; IRIX64 6.2 IP25)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: Bug
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

On an Indigo running 6.2 and Peformer 2.0
I have encounterd a strange bug with pfSequence;
If I substitute a pfSwitch node in the hierarchy
I don't have a problem and the code runs fine. 
The fault appears to lie with the call to pfGetSeqFrame.
The same thing happens in my C++ version.
I recall there were some really BIG patch sets I used
to have on my RE running 6.2 and my IR running 6.4
(the same code worked find on these machines),
but I forgot the numbers.

 0 pfSequence::nb_getFrame(int*) const(0x1807c400, 0x0, 0x1badbebe,
0x5f854664) ["../../../lib/libpf/pfSequence.C":287, 0x5e9261bc]
   1 pfGetSeqFrame(0x1807c400, 0x0, 0x1badbebe, 0x5f854664)
["../../../lib/libpf/cSequence.C":181, 0x5e937204]
   2 main(0x2, 0x7fff2f54, 0x1badbebe, 0x5f854664) ["../bnl.c":607,
0x40500c]
   3 __istart() ["crt1tinit.s":13, 0x403a30]

B. 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  Tue May 26 15:58:53 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA26763 for info-performer-dist@holodeck.engr.sgi.com; Tue, 26 May 1998 15:53:30 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id PAA26736 for <info-performer@holodeck.engr.sgi.com>; Tue, 26 May 1998 15:53:29 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id PAA04140
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 26 May 1998 15:53:29 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from dillinger.io.com (dillinger.io.com [199.170.88.11]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA07037
	for <info-performer@sgi.com>; Tue, 26 May 1998 15:53:25 -0700 (PDT)
	mail_from (markc@io.com)
From: markc@io.com
Received: from localhost (markc@localhost)
	by dillinger.io.com (8.8.7/8.8.5) with SMTP id RAA28043
	for <info-performer@sgi.com>; Tue, 26 May 1998 17:53:24 -0500 (CDT)
X-Authentication-Warning: dillinger.io.com: markc owned process doing -bs
Date: Tue, 26 May 1998 17:53:24 -0500 (CDT)
To: info-performer@sgi.com
Subject: Re: pfLPointState -- again.
In-Reply-To: <Pine.BSI.3.96.980526143008.28793A-100000@pentagon.io.com>
Message-ID: <Pine.BSF.3.96.980526174623.27725A-100000@dillinger.io.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

Hello,

  My bad ;)  pfdMakeShared just doing it's job.  

Much Better,

markc@io.com
mac@wesson.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 May 26 23:13:35 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id XAA12862 for info-performer-dist@holodeck.engr.sgi.com; Tue, 26 May 1998 23:03:15 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id XAA12835 for <info-performer@holodeck.engr.sgi.com>; Tue, 26 May 1998 23:03:14 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id XAA25565
	for <info-performer@cthulhu.engr.sgi.com>;
	Tue, 26 May 1998 23:03:13 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from alijku04.edvz.uni-linz.ac.at (alijku04.edvz.uni-linz.ac.at [140.78.182.1]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA13728
	for <info-performer@sgi.com>; Tue, 26 May 1998 23:03:02 -0700 (PDT)
	mail_from (michael.haller@jk.uni-linz.ac.at)
Received: from merlin (z439.Raab-Heim.Uni-Linz.AC.AT [193.171.33.17])
	by alijku04.edvz.uni-linz.ac.at (8.8.8/8.8.8) with SMTP id IAA21032
	for <info-performer@sgi.com>; Wed, 27 May 1998 08:04:39 +0200
Message-Id: <199805270604.IAA21032@alijku04.edvz.uni-linz.ac.at>
X-Sender: k3029e8@pop.uni-linz.ac.at
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Wed, 27 May 1998 08:06:12 +0200
To: info-performer@sgi.com
From: Michael Haller <michael.haller@jk.uni-linz.ac.at>
Subject: clouds
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Status: O

Hi *,

  I have to implement a cloud with iris performer 2.0. Which way would be
the best? Are there any similar (available) sources which represent a fire,
clouds, ....

Thx in advance,
  Michael.

=======================================================================
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 May 27 00:46:13 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id AAA13363 for info-performer-dist@holodeck.engr.sgi.com; Wed, 27 May 1998 00:26:18 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id AAA13336 for <info-performer@holodeck.engr.sgi.com>; Wed, 27 May 1998 00:26:17 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id AAA66422
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 27 May 1998 00:26:16 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from bifrost.digi.lego.com (balder.digi.lego.com [194.239.78.1]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id AAA01297
	for <info-performer@sgi.com>; Wed, 27 May 1998 00:26:13 -0700 (PDT)
	mail_from (svend@digi.lego.com)
Received: (from gproxy@localhost) by bifrost.digi.lego.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA28575 for <@bifrost.digi.lego.com:info-performer@sgi.com>; Wed, 27 May 1998 09:26:52 +0200
Received: from puck.digi.lego.com(171.20.167.61) by bifrost via smap (3.2)
	id xma028572; Wed, 27 May 98 09:26:43 +0200
Received: from digi.lego.com (localhost [127.0.0.1]) by puck.digi.lego.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA14321 for <info-performer@sgi.com>; Wed, 27 May 1998 09:26:41 +0200
Sender: svend@digi.lego.com
Message-ID: <356BC02F.368DA943@digi.lego.com>
Date: Wed, 27 May 1998 09:26:41 +0200
From: Svend Tang-Petersen <svend@digi.lego.com>
Organization: LEGO
X-Mailer: Mozilla 4.04 [en] (X11; I; IRIX 6.3 IP32)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: [Fwd: clouds]
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O



> Hi Micheal.
>
> Clouds: a repeated texture on a large polygon, and you change texture
> (u,v) as a function of
>               time to make it move.
>
> Fire: find a sequence of textures/movie clip with a fire. Load the
> textures into an array, and
>          change the texture on your polygon/billboard for each frame to
> animate.
>
> --
>
>  Svend Tang-Petersen, MSc
>
>  Silicon Graphics
>  Stationsparken 25
>  2600 Glostrup
>  Denmark
>
>  svend@copen.sgi.com
>
> Currently:
>
>  LEGO, wiZards
>  Kloevermarken 120
>  7190 Billund
>  Denmark
>
>  svend@digi.lego.com
>
>   ------------------------------------------------------------------------
>
> /* clouds.c     Do moving clouds, and add ligthing effects
>  *
>  * Usage:       clouds
>  *
>  * Key commands:
>  *
>  * <f> key      - decrease requested frame rate
>  * <F> key      - increase requested frame rate
>  * <p> key      - change phase
>  * <h> key      - print help
>  * <l> key      - toggle load managment
>  * <r> key      - reset transformer position
>  * <s> key      - toggle statistics
>  * ESCAPE key   - exit program
>  *
>  */
>
> #include <Performer/pf.h>
> #include <Performer/pfdu.h>
> #include <Performer/pfutil.h>
> #include <Performer/pfui.h>
> #include <stdio.h>
>
> /* Function prototypes */
>
> void windowSetup( char *title );
> void sceneSetup(void);
> void channelSetup(void);
> void xformerSetup(void);
> void updateView(void);
> void updateSim(void);
> void changeFrameRate( int increment );
> void changePhase(void);
> void toggleLoadMgmt(void);
> void handleEvents(void);
> void printHelp( char *progName );
>
> /* Global variables */
>
> pfScene         *scene;
> pfChannel       *chan;
> pfGeoSet        *cloud_gset;
> pfVec2          *cloud_texcoords;
> char            *progName;
> int              exitFlag = 0, showStats = 0, handleStress = 0;
> float            cloud_x = 0.0f;
> pfuEventStream   events;
> pfuMouse         mouse;
> pfiTDFXformer   *xformer;
>
> int main( int argc, char *argv[] )
> {
>
>  extern char            *progName;
>  extern int              exitFlag;
>
>  /* Initialize Performer and create the pipe */
>
>  pfInit();
>  pfuInitUtil();
>  pfiInit();
>  pfConfig();
>
>  /* Set up a window, scene graph and channel */
>
>  progName = argv[0];
>  windowSetup( progName );
>  sceneSetup();
>  channelSetup();
>  xformerSetup();
>
>  /* Simulate */
>
>  printHelp( progName );
>  pfInitClock( 0.0f );
>  pfPhase( PFPHASE_FREE_RUN );
>  pfFrameRate( 30.0f );
>
>  while ( !exitFlag ) {
>        pfSync();
>        updateView();
>        pfFrame();
>        updateSim();
>  };
>
>  /* Clean up */
>
>  pfuExitInput();
>  pfuExitUtil();
>  pfExit();
>  return 0;
>
> }
>
> void windowSetup( char *title )
> {
>
>  pfPipe         *pipe;
>  pfPipeWindow   *win;
>
>  pipe = pfGetPipe(0);
>  win = pfNewPWin( pipe );
>  pfPWinName( win, title );
>  pfPWinSize( win, 800, 500 );
>
>  pfPWinType( win, PFPWIN_TYPE_X );
>  pfuInitInput( win, PFUINPUT_X );
>
>  pfOpenPWin( win );
>
> }
>
> void sceneSetup(void)
> {
>
>  extern pfScene         *scene;
>  extern pfGeoSet        *cloud_gset;
>  extern pfVec2          *cloud_texcoords;
>  pfGeode                *cloud_geode;
>  pfGeoState             *cloud_gstate;
>  pfNode                 *model;
>  pfVec3                 *cloud_verts;
>  pfVec4                 *cloud_colors;
>  pfTexture              *cloud_tex;
>  pfTexEnv               *cloud_tev;
>  pfLightSource          *light;
>  void                   *arena;
>
>  scene = pfNewScene();
>  light = pfNewLSource();
> /* pfLSourceOn( light ); */
>  pfLSourcePos( light, 2500.0f, 2200.0f, 2000.0f, 0.0f );
>  pfLSourceColor( light, PFLT_AMBIENT, 1.0f, 1.0f, 1.0f );
>  pfAddChild( scene, light );
>
>  pfFilePath("/usr/share/Performer/data/town:.:Textures");
>  model = pfdLoadFile("town.pfb");
>  pfAddChild( scene, model );
>
>  /* Add a top polygon to hold clouds that slide */
>
>  cloud_gset = pfNewGSet( arena );
>  pfGSetPrimType( cloud_gset, PFGS_QUADS );
>  pfGSetNumPrims( cloud_gset, 1 );
>
>  cloud_geode = pfNewGeode();
>  pfAddGSet( cloud_geode, cloud_gset );
>
>  cloud_verts=     (pfVec3 *)pfMalloc( 4 * sizeof(pfVec3), arena );
>  cloud_colors=    (pfVec4 *)pfMalloc( 4 * sizeof(pfVec4), arena );
>  cloud_texcoords= (pfVec2 *)pfMalloc( 4 * sizeof(pfVec2), arena );
>
>  pfSetVec3( cloud_verts[0],-1000.0f,-1000.0f, 550.0f );
>  pfSetVec3( cloud_verts[1],-1000.0f, 6000.0f, 550.0f );
>  pfSetVec3( cloud_verts[2], 6000.0f, 6000.0f, 550.0f );
>  pfSetVec3( cloud_verts[3], 6000.0f,-1000.0f, 550.0f );
>
>  pfSetVec4( cloud_colors[0], 1.0f, 1.0f, 1.0f, 1.0f );
>  pfSetVec4( cloud_colors[1], 1.0f, 1.0f, 1.0f, 1.0f );
>  pfSetVec4( cloud_colors[2], 1.0f, 1.0f, 1.0f, 1.0f );
>  pfSetVec4( cloud_colors[3], 1.0f, 1.0f, 1.0f, 1.0f );
>
>  pfSetVec2( cloud_texcoords[0], 0.0f, 0.0f );
>  pfSetVec2( cloud_texcoords[1], 0.0f, 4.0f );
>  pfSetVec2( cloud_texcoords[2], 4.0f, 4.0f );
>  pfSetVec2( cloud_texcoords[3], 4.0f, 0.0f );
>
>  pfGSetAttr( cloud_gset, PFGS_COORD3,    PFGS_PER_VERTEX, cloud_verts, NULL );
>  pfGSetAttr( cloud_gset, PFGS_COLOR4,    PFGS_PER_VERTEX, cloud_colors, NULL );
>  pfGSetAttr( cloud_gset, PFGS_TEXCOORD2, PFGS_PER_VERTEX, cloud_texcoords, NULL );
>
>  cloud_gstate = pfNewGState( arena );
>  cloud_tex = pfNewTex( arena );
>  pfTexFormat( cloud_tex, PFTEX_INTERNAL_FORMAT, PFTEX_RGB_5 );
>  pfLoadTexFile( cloud_tex, "clouds.rgb" );
>  pfTexRepeat( cloud_tex, PFTEX_WRAP_S, PFTEX_REPEAT );
>  pfTexRepeat( cloud_tex, PFTEX_WRAP_T, PFTEX_REPEAT );
>
>  cloud_tev = pfNewTEnv( arena );
>  pfGStateMode( cloud_gstate, PFSTATE_ENTEXTURE, PF_ON );
>  pfGStateAttr( cloud_gstate, PFSTATE_TEXTURE, cloud_tex );
>  pfGStateAttr( cloud_gstate, PFSTATE_TEXENV,  cloud_tev );
>
>  pfGSetGState( cloud_gset, cloud_gstate );
>  pfAddChild( scene, cloud_geode );
>
> }
>
> void channelSetup(void)
> {
>
>  extern pfScene         *scene;
>  extern pfChannel       *chan;
>  pfPipe                 *pipe;
>  pfSphere                bsphere;
>  pfEarthSky             *esky;
>
>  pipe = pfGetPipe(0);
>  chan = pfNewChan( pipe );
>  pfChanScene( chan, scene );
>
>  esky = pfNewESky();
>  pfESkyColor( esky, PFES_GRND_NEAR, 0.0f, 0.4f, 0.0f, 1.0f );
>  pfESkyColor( esky, PFES_GRND_FAR,  0.0f, 0.4f, 0.0f, 1.0f );
>  pfESkyMode( esky, PFES_BUFFER_CLEAR, PFES_SKY_CLEAR );
>  pfChanESky( chan, esky );
>
>  pfGetNodeBSphere( scene, &bsphere );
>  pfChanNearFar( chan, 1.0f, 100.0f * bsphere.radius );
>  pfChanFOV( chan, 60.0f, -1.0f );
>
> }
>
> void xformerSetup(void)
> {
>
>  extern pfScene         *scene;
>  extern pfChannel       *chan;
>  extern pfuEventStream   events;
>  extern pfiTDFXformer   *xformer;
>  extern pfuMouse         mouse;
>  pfCoord                 view;
>  pfSphere                bsphere;
>  pfBox                   bbox;
>  float                   speed;
>
>  xformer = pfiNewTDFXformer( pfGetSharedArena() );
>  pfiXformerAutoInput( xformer, chan, &mouse, &events );
>  pfiXformerAutoPosition( xformer, chan, NULL );
>  pfiSelectXformerModel( xformer, PFITDF_FLY );
>
>  pfGetNodeBSphere( scene, &bsphere );
>  pfSetVec3( view.xyz, 2472.0f, 2200.0f, 4.0f );
>  pfSetVec3( view.hpr, -110.0f, 0.0f, 0.0f );
>  pfiXformerCoord( xformer, &view );
>  pfiXformerResetCoord( xformer, &view );
>
>  pfuTravCalcBBox( scene, &bbox );
>  speed = bsphere.radius / 30.0f;
>  pfiXformerLimits( xformer, speed, 90.0f, speed/2.0f, &bbox );
>
> }
>
> void updateView(void)
> {
>
>  extern pfuMouse         mouse;
>  extern pfiTDFXformer   *xformer;
>
>  pfuGetMouse( &mouse );
>  pfiUpdateXformer( xformer );
>
> }
>
> void updateSim(void)
> {
>
>  extern pfChannel       *chan;
>  extern int              showStats;
>  extern pfVec2          *cloud_texcoords;
>  extern pfGeoSet        *cloud_gset;
>  extern float            cloud_x;
>  float                   time;
>  int                     i;
>
>  time = pfGetTime();
>
>  /* make the sky drift */
>
>  cloud_x = cloud_x + 0.001f;
>  if (cloud_x > 0.0f) cloud_x = cloud_x - 4.0f;
>
>  pfSetVec2( cloud_texcoords[0], 0.0f, -cloud_x );
>  pfSetVec2( cloud_texcoords[1], 0.0f, -cloud_x + 4.0f );
>  pfSetVec2( cloud_texcoords[2], 4.0f, -cloud_x + 4.0f );
>  pfSetVec2( cloud_texcoords[3], 4.0f, -cloud_x );
>
>  pfGSetAttr( cloud_gset, PFGS_TEXCOORD2, PFGS_PER_VERTEX,
>              cloud_texcoords, NULL );
>
>  /* check keyboard events and draw channel stats */
>
>  handleEvents();
>  if (showStats) pfDrawChanStats( chan );
>
> }
>
> void changeFrameRate(int increment)
> {
>
>  float  vrate;
>  int    fields;
>
>  fields = pfGetFieldRate();
>  fields += increment;
>
>  if ( fields < 0 ) fields = 1;
>
>  pfFieldRate( fields );
>
> }
>
> void changePhase(void)
> {
>
>  int    currPhase;
>
>  currPhase = pfGetPhase();
>  switch (currPhase) {
>
>         case PFPHASE_FREE_RUN : currPhase = PFPHASE_LIMIT;
>                                 break;
>
>         case PFPHASE_LIMIT    : currPhase = PFPHASE_FLOAT;
>                                 break;
>
>         case PFPHASE_FLOAT    : currPhase = PFPHASE_LOCK;
>                                 break;
>
>         case PFPHASE_LOCK     : currPhase = PFPHASE_FREE_RUN;
>                                 break;
>
>         default               : currPhase = PFPHASE_FREE_RUN;
>                                 break;
>
>  };
>
>  pfPhase(currPhase);
>
> }
>
> void toggleLoadMgmt(void)
> {
>
>  extern pfChannel       *chan;
>  float                   frac = 1.0, lo = 0.6, hi = 0.8;
>  float                   scale = 0.1, max = 30.0f;
>
>  handleStress = !handleStress;
>  if (!handleStress) {
>     scale = 0.0f;
>     pfChanStress( chan, 1 );
>  }
>
>  pfChanStressFilter( chan, frac, lo, hi, scale, max );
>  printf("Load managment is %s\n", handleStress ? "ON" : "OFF" );
>
> }
>
> void handleEvents(void)
> {
>
>  extern pfuEventStream   events;
>  extern char            *progName;
>  extern int              exitFlag;
>  int                     i, j;
>  int                     key, dev, val, numDevs;
>  pfuEventStream         *pEvents = &events;
>
>  pfuGetEvents( &events );
>  numDevs = pEvents -> numDevs;
>
>  for ( j= 0; j < numDevs; ++j ) {
>
>      dev = pEvents -> devQ[j];
>      val = pEvents -> devVal[j];
>
>      if ( pEvents -> devCount[dev] > 0 ) {
>
>       switch ( dev ) {
>
>         case PFUDEV_REDRAW:     pEvents -> devCount[dev] = 0;
>                                 break;
>
>         case PFUDEV_WINQUIT:    exitFlag = 1;
>                                 pEvents -> devCount[dev] = 0;
>                                 break;
>
>         case PFUDEV_KEYBD:      for ( i= 0; i < pEvents -> numKeys; ++i ) {
>
>                                   key = pEvents -> keyQ[i];
>                                   if ( pEvents -> keyCount[key] ) {
>
>                                      switch ( key ) {
>
>                                         case  27: exitFlag = 1;
>                                                   break;
>
>                                         case 'f': changeFrameRate(1); break;
>
>                                         case 'F': changeFrameRate(-1); break;
>
>                                         case 'p': changePhase(); break;
>
>                                         case 'h': printHelp( progName );
>                                                   break;
>
>                                         case 'r': pfiStopXformer( xformer );
>                                                   pfiResetXformerPosition( xformer );
>                                                   break;
>
>                                         case 'l': toggleLoadMgmt(); break;
>
>                                         case 's': showStats = !showStats;
>                                                   break;
>
>                                         default : break;
>
>                                      };
>                                   };
>                                 };
>
>                                 pEvents -> devCount[dev] = 0;
>                                 break;
>
>         default:                break;
>
>       }
>      }
>  };
>
>  pEvents -> numKeys = 0;
>  pEvents -> numDevs = 0;
>
> }
>
> void printHelp( char *progName )
> {
>
>  printf("\n%s - playing with fire\n\n"
>         "<f> key\t\t\t - decrease the requested frame rate\n"
>         "<F> key\t\t\t - increase the requested frame rate\n"
>         "<p> key\t\t\t - change phase\n"
>         "<h> key\t\t\t - print help\n"
>         "<r> key\t\t\t - reset transformer position\n"
>         "<l> key\t\t\t - toggle load managment\n"
>         "<s> key\t\t\t - toggle graphics stats\n"
>         "ESCAPE key\t\t - exit the program\n\n",
>         progName );
>
> }
>
>   ------------------------------------------------------------------------
>
>                     Name: clouds.rgb
>    clouds.rgb       Type: RGB Image (image/x-rgb)
>                 Encoding: base64
>
>   ------------------------------------------------------------------------
>
> /* flames.c     make a moving and textured flag.
>  *              Add sequence of animated textures.
>  *              Add moving clouds.
>  *
>  * Usage:       flames
>  *
>  * Key commands:
>  *
>  * <f> key      - decrease requested frame rate
>  * <F> key      - increase requested frame rate
>  * <p> key      - change phase
>  * <h> key      - print help
>  * <l> key      - toggle load managment
>  * <r> key      - reset transformer position
>  * <s> key      - toggle statistics
>  * ESCAPE key   - exit program
>  *
>  */
>
> #include <Performer/pf.h>
> #include <Performer/pfdu.h>
> #include <Performer/pfutil.h>
> #include <Performer/pfui.h>
> #include <stdio.h>
>
> /* type definitions */
>
> typedef struct MovieData
> {
>  pfTexture      *frame;
> } MovieData;
>
> /* Function prototypes */
>
> void windowSetup( char *title );
> void sceneSetup(void);
> void channelSetup(void);
> void xformerSetup(void);
> void updateView(void);
> void updateSim(void);
> void changeFrameRate( int increment );
> void changePhase(void);
> void toggleLoadMgmt(void);
> void handleEvents(void);
> void printHelp( char *progName );
>
> /* Global variables */
>
> pfScene         *scene;
> pfChannel       *chan;
> pfDCS           *rotDCS;
> pfGeoSet        *gset, *bb_gset, *cloud_gset;
> pfGeoState      *bb_gstate;
> pfVec2          *cloud_texcoords;
> pfVec3          *verts;
> pfTexture       *frame;
> MovieData        movie[32];
> char            *progName;
> int              exitFlag = 0, showStats = 0, handleStress = 0, frame_no = 0;
> float            cloud_x = 0.0f;
> pfuEventStream   events;
> pfuMouse         mouse;
> pfiTDFXformer   *xformer;
>
> int main( int argc, char *argv[] )
> {
>
>  extern char            *progName;
>  extern int              exitFlag;
>
>  /* Initialize Performer and create the pipe */
>
>  pfInit();
>  pfuInitUtil();
>  pfiInit();
>  pfConfig();
>
>  /* Set up a window, scene graph and channel */
>
>  progName = argv[0];
>  windowSetup( progName );
>  sceneSetup();
>  channelSetup();
>  xformerSetup();
>
>  /* Simulate */
>
>  printHelp( progName );
>  pfInitClock( 0.0f );
>  pfPhase( PFPHASE_FREE_RUN );
>  pfFrameRate( 30.0f );
>
>  while ( !exitFlag ) {
>        pfSync();
>        updateView();
>        pfFrame();
>        updateSim();
>  };
>
>  /* Clean up */
>
>  pfuExitInput();
>  pfuExitUtil();
>  pfExit();
>  return 0;
>
> }
>
> void windowSetup( char *title )
> {
>
>  pfPipe         *pipe;
>  pfPipeWindow   *win;
>
>  pipe = pfGetPipe(0);
>  win = pfNewPWin( pipe );
>  pfPWinName( win, title );
>  pfPWinSize( win, 800, 500 );
>
>  pfPWinType( win, PFPWIN_TYPE_X );
>  pfuInitInput( win, PFUINPUT_X );
>
>  pfOpenPWin( win );
>
> }
>
> void sceneSetup(void)
> {
>
>  extern pfScene         *scene;
>  extern pfGeoSet        *gset, *bb_gset, *cloud_gset;
>  extern pfVec3          *verts;
>  extern pfTexture       *frame;
>  extern MovieData        movie[32];
>  extern pfGeoState      *bb_gstate;
>  extern pfVec2          *cloud_texcoords;
>  pfGeode                *geode, *cloud_geode;
>  pfGeoState             *gstate, *cloud_gstate;
>  pfNode                 *model;
>  pfVec2                 *texcoords, *bb_texcoords;
>  pfVec3                  vec3,      *bb_verts,     *cloud_verts;
>  pfVec4                 *colors,    *bb_colors,    *cloud_colors;
>  pfTexture              *tex,                      *cloud_tex;
>  pfTexEnv               *tev,       *bb_tev,       *cloud_tev;
>  pfSCS                  *scs;
>  pfMatrix               mat;
>  pfLightSource          *light;
>  pfBillboard            *bill;
>  void                   *arena;
>
>  int                     i;
>  char                   *filename;
>
>  scene = pfNewScene();
>  light = pfNewLSource();
> /* pfLSourceOn( light ); */
>  pfLSourcePos( light, 2500.0f, 2200.0f, 2000.0f, 0.0f );
>  pfLSourceColor( light, PFLT_AMBIENT, 1.0f, 1.0f, 1.0f );
>  pfAddChild( scene, light );
>
>  pfFilePath("/usr/share/Performer/data/town:.:Textures");
>  model = pfdLoadFile("town.pfb");
>  pfAddChild( scene, model );
>
>  /* make a flag to wave */
>
>  arena = pfGetSharedArena();
>  gset = pfNewGSet( arena );
>  pfGSetPrimType( gset, PFGS_QUADS );
>  pfGSetNumPrims( gset, 10 );
>
>  verts     = (pfVec3 *)pfMalloc( 40 * sizeof(pfVec3), arena );
>  colors    = (pfVec4 *)pfMalloc( 40 * sizeof(pfVec4), arena );
>  texcoords = (pfVec2 *)pfMalloc( 40 * sizeof(pfVec2), arena );
>
>  for ( i= 0; i < 10; i++ ) {
>
> /* pfSetVec2( texcoords[2*i  ], 0.1f*i, 1.0f);
>    pfSetVec2( texcoords[2*i+1], 0.1f*i, 0.0f);
>
>    pfSetVec3(  verts[2*i  ], i * 2.0f, 0.0f,  10.0f );
>    pfSetVec3(  verts[2*i+1], i * 2.0f, 0.0f, -10.0f );
>
>    pfSetVec4( colors[2*i  ], 1.0, 1.0, 1.0, 1.0);
>    pfSetVec4( colors[2*i+1], 1.0, 1.0, 1.0, 1.0); */
>
>    pfSetVec2( texcoords[4*i  ], 0.1f*i, 1.0f);
>    pfSetVec2( texcoords[4*i+1], 0.1f*(i+1), 1.0f);
>    pfSetVec2( texcoords[4*i+2], 0.1f*(i+1), 0.0f);
>    pfSetVec2( texcoords[4*i+3], 0.1f*i, 0.0f);
>
>    pfSetVec3(  verts[4*i  ], 0.0f, i* 0.2f,  1.0f );
>    pfSetVec3(  verts[4*i+1], 0.0f, (i+1)* 0.2f,  1.0f );
>    pfSetVec3(  verts[4*i+2], 0.0f, (1+i)* 0.2f, -1.0f );
>    pfSetVec3(  verts[4*i+3], 0.0f, i* 0.2f, -1.0f );
>
>    pfSetVec4( colors[4*i  ], 1.0, 1.0, 1.0, 1.0);
>    pfSetVec4( colors[4*i+1], 1.0, 1.0, 1.0, 1.0);
>    pfSetVec4( colors[4*i+2], 1.0, 1.0, 1.0, 1.0);
>    pfSetVec4( colors[4*i+3], 1.0, 1.0, 1.0, 1.0);
>
>  };
>
>  pfGSetAttr( gset, PFGS_COORD3, PFGS_PER_VERTEX, verts, NULL );
>  pfGSetAttr( gset, PFGS_COLOR4, PFGS_PER_VERTEX, colors, NULL );
>  pfGSetAttr( gset, PFGS_TEXCOORD2, PFGS_PER_VERTEX, texcoords, NULL );
>
>  geode = pfNewGeode();
>  pfAddGSet( geode, gset );
>
>  /* Load and apply a texture to flag */
>
>  gstate = pfNewGState( arena );
>  pfGStateMode( gstate, PFSTATE_CULLFACE, PFCF_OFF );
> /* pfFilePath( "." ); */
>  tex = pfNewTex( arena );
>  if ( pfLoadTexFile( tex, "wizard.rgb" ) != 0 ) {
>     pfTexRepeat( tex, PFTEX_WRAP_S, PFTEX_CLAMP );
>     pfTexRepeat( tex, PFTEX_WRAP_T, PFTEX_CLAMP );
>
>     tev = pfNewTEnv( arena );
>     pfGStateMode( gstate, PFSTATE_ENTEXTURE, PF_ON );
>     pfGStateAttr( gstate, PFSTATE_TEXTURE, tex );
>     pfGStateAttr( gstate, PFSTATE_TEXENV, tev );
>  }
>
>  pfGSetGState( gset, gstate );
>
>  pfMakeTransMat( mat, 2488.6f, 2191.97f, 5.5f );
>  scs = pfNewSCS( mat );
>
>  pfAddChild( scs, geode );
>  pfAddChild( scene, scs );
>
>  /* Add a top polygon to hold clouds that slide */
>
>  cloud_gset = pfNewGSet( arena );
>  pfGSetPrimType( cloud_gset, PFGS_QUADS );
>  pfGSetNumPrims( cloud_gset, 1 );
>
>  cloud_geode = pfNewGeode();
>  pfAddGSet( cloud_geode, cloud_gset );
>
>  cloud_verts=     (pfVec3 *)pfMalloc( 4 * sizeof(pfVec3), arena );
>  cloud_colors=    (pfVec4 *)pfMalloc( 4 * sizeof(pfVec4), arena );
>  cloud_texcoords= (pfVec2 *)pfMalloc( 4 * sizeof(pfVec2), arena );
>
>  pfSetVec3( cloud_verts[0],-1000.0f,-1000.0f, 550.0f );
>  pfSetVec3( cloud_verts[1],-1000.0f, 6000.0f, 550.0f );
>  pfSetVec3( cloud_verts[2], 6000.0f, 6000.0f, 550.0f );
>  pfSetVec3( cloud_verts[3], 6000.0f,-1000.0f, 550.0f );
>
>  pfSetVec4( cloud_colors[0], 1.0f, 1.0f, 1.0f, 1.0f );
>  pfSetVec4( cloud_colors[1], 1.0f, 1.0f, 1.0f, 1.0f );
>  pfSetVec4( cloud_colors[2], 1.0f, 1.0f, 1.0f, 1.0f );
>  pfSetVec4( cloud_colors[3], 1.0f, 1.0f, 1.0f, 1.0f );
>
>  pfSetVec2( cloud_texcoords[0], 0.0f, 0.0f );
>  pfSetVec2( cloud_texcoords[1], 0.0f, 4.0f );
>  pfSetVec2( cloud_texcoords[2], 4.0f, 4.0f );
>  pfSetVec2( cloud_texcoords[3], 4.0f, 0.0f );
>
>  pfGSetAttr( cloud_gset, PFGS_COORD3,    PFGS_PER_VERTEX, cloud_verts, NULL );
>  pfGSetAttr( cloud_gset, PFGS_COLOR4,    PFGS_PER_VERTEX, cloud_colors, NULL );
>  pfGSetAttr( cloud_gset, PFGS_TEXCOORD2, PFGS_PER_VERTEX, cloud_texcoords, NULL );
>
>  cloud_gstate = pfNewGState( arena );
>  cloud_tex = pfNewTex( arena );
>  pfTexFormat( cloud_tex, PFTEX_INTERNAL_FORMAT, PFTEX_RGB_5 );
>  pfLoadTexFile( cloud_tex, "clouds.rgb" );
>  pfTexRepeat( cloud_tex, PFTEX_WRAP_S, PFTEX_REPEAT );
>  pfTexRepeat( cloud_tex, PFTEX_WRAP_T, PFTEX_REPEAT );
>
>  cloud_tev = pfNewTEnv( arena );
>  pfGStateMode( cloud_gstate, PFSTATE_ENTEXTURE, PF_ON );
>  pfGStateAttr( cloud_gstate, PFSTATE_TEXTURE, cloud_tex );
>  pfGStateAttr( cloud_gstate, PFSTATE_TEXENV,  cloud_tev );
>
>  pfGSetGState( cloud_gset, cloud_gstate );
>  pfAddChild( scene, cloud_geode );
>
>  /* Add a single QUAD billboard with an RGBA texture */
>
>  bb_gset = pfNewGSet( arena );
>  pfGSetPrimType( bb_gset, PFGS_QUADS );
>  pfGSetNumPrims( bb_gset, 1 );
>
>  bb_verts     = (pfVec3 *)pfMalloc( 4 * sizeof(pfVec3), arena );
>  bb_colors    = (pfVec4 *)pfMalloc( 4 * sizeof(pfVec4), arena );
>  bb_texcoords = (pfVec2 *)pfMalloc( 4 * sizeof(pfVec2), arena );
>
>  pfSetVec2( bb_texcoords[0], 0.0f, 0.0f );
>  pfSetVec2( bb_texcoords[1], 1.0f, 0.0f );
>  pfSetVec2( bb_texcoords[2], 1.0f, 1.0f );
>  pfSetVec2( bb_texcoords[3], 0.0f, 1.0f );
>
>  pfSetVec3( bb_verts[0], 0.0f, 0.0f, 0.0f );
>  pfSetVec3( bb_verts[1], 2.0f, 0.0f, 0.0f );
>  pfSetVec3( bb_verts[2], 2.0f, 0.0f, 3.0f );
>  pfSetVec3( bb_verts[3], 0.0f, 0.0f, 3.0f );
>
>  pfSetVec4( bb_colors[0], 1.0, 1.0, 1.0, 1.0);
>  pfSetVec4( bb_colors[1], 1.0, 1.0, 1.0, 1.0);
>  pfSetVec4( bb_colors[2], 1.0, 1.0, 1.0, 1.0);
>  pfSetVec4( bb_colors[3], 1.0, 1.0, 1.0, 1.0);
>
>  pfGSetAttr( bb_gset, PFGS_COORD3, PFGS_PER_VERTEX, bb_verts, NULL );
>  pfGSetAttr( bb_gset, PFGS_COLOR4, PFGS_PER_VERTEX, bb_colors, NULL );
>  pfGSetAttr( bb_gset, PFGS_TEXCOORD2, PFGS_PER_VERTEX, bb_texcoords, NULL );
>
>  bb_gstate = pfNewGState( arena );
>  pfGStateMode( bb_gstate, PFSTATE_CULLFACE, PFCF_OFF );
> /* pfFilePath("Textures"); */
>  frame = pfNewTex( arena );
>  pfTexFormat( frame, PFTEX_INTERNAL_FORMAT, PFTEX_RGBA_8 );
>  pfLoadTexFile( frame, "f01");
>  pfTexRepeat( frame, PFTEX_WRAP_S, PFTEX_CLAMP );
>  pfTexRepeat( frame, PFTEX_WRAP_T, PFTEX_CLAMP );
>
>  bb_tev = pfNewTEnv( arena );
>  pfGStateMode( bb_gstate, PFSTATE_TRANSPARENCY, PFTR_ON );
>  pfGStateMode( bb_gstate, PFSTATE_ENTEXTURE, PF_ON );
>  pfGStateAttr( bb_gstate, PFSTATE_TEXTURE, frame );
>  pfGStateAttr( bb_gstate, PFSTATE_TEXENV, bb_tev );
>
>  pfGSetGState( bb_gset, bb_gstate );
>
>  bill= pfNewBboard();
>  pfSetVec3( vec3, 0.0f, 0.0f, 1.0f );
>  pfBboardAxis( bill, vec3 );
>  pfSetVec3( vec3, 2507.0f, 2199.8f, 8.2f );
>  pfBboardPos( bill, 0, vec3 );
>  pfAddGSet( bill, bb_gset );
>  pfAddChild( scene, bill );
>
>  /* load sequence of images for flame animation */
>
>  filename = (char *)malloc(10 * sizeof(char));
> /* pfFilePath("Textures"); */
>  for (i= 0; i < 32 ; i++ ) {
>   movie[i].frame = pfNewTex( arena );
>   printf("f%02i\n", i+1);
>   sprintf( filename, "f%02i", i+1);
>   pfTexFormat( movie[i].frame, PFTEX_INTERNAL_FORMAT, PFTEX_RGBA_8 );
>   pfLoadTexFile( movie[i].frame, filename );
>   pfTexRepeat(   movie[i].frame, PFTEX_WRAP_S, PFTEX_CLAMP );
>   pfTexRepeat(   movie[i].frame, PFTEX_WRAP_T, PFTEX_CLAMP );
>  }
>
> }
>
> void channelSetup(void)
> {
>
>  extern pfScene         *scene;
>  extern pfChannel       *chan;
>  pfPipe                 *pipe;
>  pfSphere                bsphere;
>  pfEarthSky             *esky;
>
>  pipe = pfGetPipe(0);
>  chan = pfNewChan( pipe );
>  pfChanScene( chan, scene );
>
>  esky = pfNewESky();
>  pfESkyColor( esky, PFES_GRND_NEAR, 0.0f, 0.4f, 0.0f, 1.0f );
>  pfESkyColor( esky, PFES_GRND_FAR,  0.0f, 0.4f, 0.0f, 1.0f );
>  pfESkyMode( esky, PFES_BUFFER_CLEAR, PFES_SKY_CLEAR );
>  pfChanESky( chan, esky );
>
>  pfGetNodeBSphere( scene, &bsphere );
>  pfChanNearFar( chan, 1.0f, 100.0f * bsphere.radius );
>  pfChanFOV( chan, 60.0f, -1.0f );
>
> }
>
> void xformerSetup(void)
> {
>
>  extern pfScene         *scene;
>  extern pfChannel       *chan;
>  extern pfuEventStream   events;
>  extern pfiTDFXformer   *xformer;
>  extern pfuMouse         mouse;
>  pfCoord                 view;
>  pfSphere                bsphere;
>  pfBox                   bbox;
>  float                   speed;
>
>  xformer = pfiNewTDFXformer( pfGetSharedArena() );
>  pfiXformerAutoInput( xformer, chan, &mouse, &events );
>  pfiXformerAutoPosition( xformer, chan, NULL );
>  pfiSelectXformerModel( xformer, PFITDF_FLY );
>
>  pfGetNodeBSphere( scene, &bsphere );
>  pfSetVec3( view.xyz, 2472.0f, 2200.0f, 4.0f );
>  pfSetVec3( view.hpr, -110.0f, 0.0f, 0.0f );
>  pfiXformerCoord( xformer, &view );
>  pfiXformerResetCoord( xformer, &view );
>
>  pfuTravCalcBBox( scene, &bbox );
>  speed = bsphere.radius / 30.0f;
>  pfiXformerLimits( xformer, speed, 90.0f, speed/2.0f, &bbox );
>
> }
>
> void updateView(void)
> {
>
>  extern pfuMouse         mouse;
>  extern pfiTDFXformer   *xformer;
>
>  pfuGetMouse( &mouse );
>  pfiUpdateXformer( xformer );
>
> }
>
> void updateSim(void)
> {
>
>  extern pfChannel       *chan;
>  extern int              showStats, frame_no;
>  extern pfVec2          *cloud_texcoords;
>  extern pfVec3          *verts;
>  extern pfGeoSet        *gset, *cloud_gset;
>  extern pfGeoState      *bb_gstate;
>  extern pfTexture       *frame;
>  extern MovieData        movie[32];
>  extern int              frame_no;
>  extern float            cloud_x;
>  float                   sin, cos, sin1, cos1, time;
>  int                     i;
>
>  time = pfGetTime();
>
>  /* make the sky drift */
>
>  cloud_x = cloud_x + 0.001f;
>  if (cloud_x > 0.0f) cloud_x = cloud_x - 4.0f;
>
>  pfSetVec2( cloud_texcoords[0], 0.0f, -cloud_x );
>  pfSetVec2( cloud_texcoords[1], 0.0f, -cloud_x + 4.0f );
>  pfSetVec2( cloud_texcoords[2], 4.0f, -cloud_x + 4.0f );
>  pfSetVec2( cloud_texcoords[3], 4.0f, -cloud_x );
>
>  pfGSetAttr( cloud_gset, PFGS_TEXCOORD2, PFGS_PER_VERTEX, cloud_texcoords, NULL );
>
>  /* wave the flag */
>
>  for (i= 0; i < 10 ; i++ ) {
>    pfSinCos( time *120.0f - 60.0f * i, &sin, &cos );
>    pfSinCos( time *120.0f - 60.0f *(i+1), &sin1, &cos1 );
>    pfSetVec3(  verts[4*i  ], i*    0.02f* cos ,     i* 0.2f,  1.0f - i*i*0.005f );
>    pfSetVec3(  verts[4*i+1], (i+1)*0.02f* cos1, (i+1)* 0.2f,  1.0f - (i+1)*(i+1)*0.005f );
>    pfSetVec3(  verts[4*i+2], (i+1)*0.02f* cos1, (1+i)* 0.2f, -1.0f - (i+1)*(i+1)*0.005f );
>    pfSetVec3(  verts[4*i+3], i*    0.02f* cos ,     i* 0.2f, -1.0f - i*i*0.005f );
>  };
>  pfGSetAttr( gset, PFGS_COORD3, PFGS_PER_VERTEX, verts, NULL );
>
>  /* Change the flame texture */
>
> /* frame_no = ((int) (16.0f*time) ) % 32; */
>  frame_no = ( frame_no + 1 ) % 32;
>  frame    = movie[frame_no].frame;
>  pfGStateAttr( bb_gstate, PFSTATE_TEXTURE, frame );
>
>  /* check keyboard events and draw channel stats */
>
>  handleEvents();
>  if (showStats) pfDrawChanStats( chan );
>
> }
>
> void changeFrameRate(int increment)
> {
>
>  float  vrate;
>  int    fields;
>
>  fields = pfGetFieldRate();
>  fields += increment;
>
>  if ( fields < 0 ) fields = 1;
>
>  pfFieldRate( fields );
>
> }
>
> void changePhase(void)
> {
>
>  int    currPhase;
>
>  currPhase = pfGetPhase();
>  switch (currPhase) {
>
>         case PFPHASE_FREE_RUN : currPhase = PFPHASE_LIMIT;
>                                 break;
>
>         case PFPHASE_LIMIT    : currPhase = PFPHASE_FLOAT;
>                                 break;
>
>         case PFPHASE_FLOAT    : currPhase = PFPHASE_LOCK;
>                                 break;
>
>         case PFPHASE_LOCK     : currPhase = PFPHASE_FREE_RUN;
>                                 break;
>
>         default               : currPhase = PFPHASE_FREE_RUN;
>                                 break;
>
>  };
>
>  pfPhase(currPhase);
>
> }
>
> void toggleLoadMgmt(void)
> {
>
>  extern pfChannel       *chan;
>  float                   frac = 1.0, lo = 0.6, hi = 0.8;
>  float                   scale = 0.1, max = 30.0f;
>
>  handleStress = !handleStress;
>  if (!handleStress) {
>     scale = 0.0f;
>     pfChanStress( chan, 1 );
>  }
>
>  pfChanStressFilter( chan, frac, lo, hi, scale, max );
>  printf("Load managment is %s\n", handleStress ? "ON" : "OFF" );
>
> }
>
> void handleEvents(void)
> {
>
>  extern pfuEventStream   events;
>  extern char            *progName;
>  extern int              exitFlag;
>  int                     i, j;
>  int                     key, dev, val, numDevs;
>  pfuEventStream         *pEvents = &events;
>
>  pfuGetEvents( &events );
>  numDevs = pEvents -> numDevs;
>
>  for ( j= 0; j < numDevs; ++j ) {
>
>      dev = pEvents -> devQ[j];
>      val = pEvents -> devVal[j];
>
>      if ( pEvents -> devCount[dev] > 0 ) {
>
>       switch ( dev ) {
>
>         case PFUDEV_REDRAW:     pEvents -> devCount[dev] = 0;
>                                 break;
>
>         case PFUDEV_WINQUIT:    exitFlag = 1;
>                                 pEvents -> devCount[dev] = 0;
>                                 break;
>
>         case PFUDEV_KEYBD:      for ( i= 0; i < pEvents -> numKeys; ++i ) {
>
>                                   key = pEvents -> keyQ[i];
>                                   if ( pEvents -> keyCount[key] ) {
>
>                                      switch ( key ) {
>
>                                         case  27: exitFlag = 1;
>                                                   break;
>
>                                         case 'f': changeFrameRate(1); break;
>
>                                         case 'F': changeFrameRate(-1); break;
>
>                                         case 'p': changePhase(); break;
>
>                                         case 'h': printHelp( progName );
>                                                   break;
>
>                                         case 'r': pfiStopXformer( xformer );
>                                                   pfiResetXformerPosition( xformer );
>                                                   break;
>
>                                         case 'l': toggleLoadMgmt(); break;
>
>                                         case 's': showStats = !showStats;
>                                                   break;
>
>                                         default : break;
>
>                                      };
>                                   };
>                                 };
>
>                                 pEvents -> devCount[dev] = 0;
>                                 break;
>
>         default:                break;
>
>       }
>      }
>  };
>
>  pEvents -> numKeys = 0;
>  pEvents -> numDevs = 0;
>
> }
>
> void printHelp( char *progName )
> {
>
>  printf("\n%s - playing with fire\n\n"
>         "<f> key\t\t\t - decrease the requested frame rate\n"
>         "<F> key\t\t\t - increase the requested frame rate\n"
>         "<p> key\t\t\t - change phase\n"
>         "<h> key\t\t\t - print help\n"
>         "<r> key\t\t\t - reset transformer position\n"
>         "<l> key\t\t\t - toggle load managment\n"
>         "<s> key\t\t\t - toggle graphics stats\n"
>         "ESCAPE key\t\t - exit the program\n\n",
>         progName );
>
> }



=======================================================================
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 May 27 06:58:07 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id GAA13957 for info-performer-dist@holodeck.engr.sgi.com; Wed, 27 May 1998 06:52:17 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id GAA13930 for <info-performer@holodeck.engr.sgi.com>; Wed, 27 May 1998 06:52:15 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id GAA47352;
	Wed, 27 May 1998 06:52:15 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id GAA20395; Wed, 27 May 1998 06:52:11 -0700 (PDT)
	mail_from (dery@discreet.com)
Received: from cuba by helios.Discreet.QC.CA
	id JAA28328; Wed, 27 May 1998 09:46:38 -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 JAA04427; Wed, 27 May 1998 09:52:09 -0400
Received: (from dery@localhost) by atlantis (950413.SGI.8.6.12/) id JAA28192; Wed, 27 May 1998 09:52:08 -0400
From: "Jean-Luc Dery" <dery@discreet.com>
Message-Id: <9805270952.ZM28081@atlantis>
Date: Wed, 27 May 1998 09:52:08 -0400
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Amit_Parghi@cuba.discreet.com, Marc_Lapierre@cuba.discreet.com,
        dery@cuba.discreet.com, info-performer@sgi.com, src@sgi.com
Subject: Performance problem with PF 2.2
Mime-Version: 1.0
Content-Type: multipart/mixed;
	boundary="PART-BOUNDARY=.19805270952.ZM28081.atlantis"
Status: O

--
--PART-BOUNDARY=.19805270952.ZM28081.atlantis
Content-Type: text/plain; charset=us-ascii

Hello,

We are in the process of upgrading our application from Performer 2.1 to 2.2;
the upgrade was very straight forward code wise but we are having a problem
with performance. The lost in performance occurs in the Performer APP stage
process. In PF 2.1, the application APP thread runs at 7-8 msec while in PF
2.2, it runs at 12-14 msec.

Performance tests on those two versions were made on the same machine
(ONYX2/4CPU/IR-2RM7/IRIX6.4).

I thus made test comparison between the application versions and have noticed
bizarre calls that are made in the PF 2.2 version of the software. Complete
analysis results are available in the attachment. Analysis was made with
speedshop, par and dbx. It shows that the 2.2 version is updating the Performer
output window position through the X server. This is somehow annoying.

The following calls are made in 2.2:

pfPipeWindow::pf_updateWindow
pfPipeWindow::pf_updateWindowOriginSize <= this is where it gets bizarre
pfWindow::pr_updateScreenOrigin
XTranslateCoordinates
_XReply
 _XRead
_X11TransRead
_X11TransShmBufRead
_read

The call to pfPipeWindow::pf_updateWindow() is made from pfSync(). In PF 2.1,
no calls are made to pfWindow::pr_updateScreenOrigin() which happens in PF 2.2.

And also:

pfPipeWindow::pf_updateWindow
pfPipeWindow::pf_updateWindowOriginSize <= and again here
XGetGeometry
_XReply
_XRead
_XWaitForReadable
_select


The comparison tests were made on the SAME machine which does not eliminate the
fact that this problem could be caused by the machine configuration interaction
with PF 2.2.

Nevertheless, further testing showed that this behavior does not occur on
ONYX2/2CPU/IR and Octane platforms.

My first guess on this is: bad HW configuration or unproper Performer
initialization (DVR,GVO,????).

Any other suggestions ?

And my questions are:

- What could be causing the APP thread to reposition the screen position if it
didn't change?
- Why is a screen/window position update made through the X server instead of
the local X display manager?
- How can I get rid of this ??!

Anybody out there ?

Thanks in advance for your help,

Jean-Luc






-- 
_____________________________________________________________________________

Jean-Luc Dery                         Discreet Logic
Technical Leader                      10 Duke Street
3-D Graphics Technology and           Montreal (Quebec), Canada, H3C 2L7
Realtime Systems                      Tel: (514) 954-7239
Email: jean-lucD@discreet.com         Fax: (514) 393-0110
_____________________________________________________________________________

--PART-BOUNDARY=.19805270952.ZM28081.atlantis
X-Zm-Content-Name: analysis.txt
Content-Description: Text
Content-Type: text/plain ; name="analysis.txt" ; charset=us-ascii

PERFORMANCE ANALYSIS PERFORMER 2.1 and PERFORMER 2.2
====================================================

ONYX 2
4 CPU 195 Mhz
1 IR-2RM7
IRIX 6.4



SSRUN OUTPUT - APP THREAD/PERFORMER 2.2
=======================================

-------------------------------------------------------------------------------
Profile listing generated Mon May 25 22:25:33 1998
    with:	prof vapourRT vapourRT.fpcsampx.17415 
-------------------------------------------------------------------------------

samples   time    CPU    FPU   Clock   N-cpu  S-interval Countsize
  23173    23s R10000 R10010 195.0MHz   1      1.0ms     4(bytes)

Each sample covers 4 bytes for every  1.0ms ( 0.00% of 23.1730s)


-------------------------------------------------------------------------------
  -p[rocedures] using pc-sampling.
  Sorted in descending order by the number of samples in each procedure.
  Unexecuted procedures are excluded.
-------------------------------------------------------------------------------

samples   time(%)      cum time(%)      procedure (dso:file)

  18340    18s( 79.1)   18s( 79.1)        _sginap (/usr/lib32/libc.so.1:/xlv24/patches/2463/work/irix/lib/libc/libc_n32_M4/sys/sginap.s)
   2640   2.6s( 11.4)   21s( 90.5)          _read (/usr/lib32/libc.so.1:/xlv24/patches/2463/work/irix/lib/libc/libc_n32_M4/sys/read.s)
   1170   1.2s(  5.0)   22s( 95.6)         _ioctl (/usr/lib32/libc.so.1:/xlv24/patches/2463/work/irix/lib/libc/libc_n32_M4/sys/ioctl.s)
    360  0.36s(  1.6)   23s( 97.1)        _select (/usr/lib32/libc.so.1:/xlv24/patches/2463/work/irix/lib/libc/libc_n32_M4/sys/select.s)
    110  0.11s(  0.5)   23s( 97.6)          _open (/usr/lib32/libc.so.1:/xlv24/patches/2463/work/irix/lib/libc/libc_n32_M4/sys/open.s)
     70  0.07s(  0.3)   23s( 97.9)  _ksigprocmask (/usr/lib32/libc.so.1:/xlv24/patches/2463/work/irix/lib/libc/libc_n32_M4/signal/ksigprocmask.s)
     70  0.07s(  0.3)   23s( 98.2)         _lseek (/usr/lib32/libc.so.1:/xlv24/patches/2463/work/irix/lib/libc/libc_n32_M4/sys/lseek.s)
     40  0.04s(  0.2)   23s( 98.4)         memcpy (/usr/lib32/libc.so.1:/xlv24/patches/2463/work/irix/lib/libc/libc_n32_M4/strings/bcopy.s)
     40  0.04s(  0.2)   23s( 98.6)  filterPutRow8 (vapourRT:vfImageLoader.C)
     40  0.04s(  0.2)   23s( 98.7)      copyImage (vapourRT:vfImageLoader.C)
     40  0.04s(  0.2)   23s( 98.9)        _unlink (/usr/lib32/libc.so.1:/xlv24/patches/2463/work/irix/lib/libc/libc_n32_M4/sys/unlink.s)
     33 0.033s(  0.1)   23s( 99.1)       _lmalloc (/usr/lib32/libc.so.1:amalloc.c)
     30  0.03s(  0.1)   23s( 99.2)        _access (/usr/lib32/libc.so.1:/xlv24/patches/2463/work/irix/lib/libc/libc_n32_M4/sys/access.s)
     30  0.03s(  0.1)   23s( 99.3)          _fork (/usr/lib32/libc.so.1:/xlv24/patches/2463/work/irix/lib/libc/libc_n32_M4/proc/fork.s)
     29 0.029s(  0.1)   23s( 99.4) pfList::search (/usr/lib32/libpf_ogl.so:../../../lib/libpr/pfList.C)
     11 0.011s(  0.0)   23s( 99.5)     applyxfilt (vapourRT:imresize.C)
     10  0.01s(  0.0)   23s( 99.5) DlArrayIterator<unsigned int>::__dt (vapourRT:DlUnsignedIntArrayInstances.C)
     10  0.01s(  0.0)   23s( 99.6) vfList<sdbFont*>::add (vapourRT:sdbFontManager.C)
     10  0.01s(  0.0)   23s( 99.6) sdbPolygon::init (vapourRT:sdbPolygon.C)
     10  0.01s(  0.0)   23s( 99.7)     getzoomrow (vapourRT:imresize.C)
     10  0.01s(  0.0)   23s( 99.7) vfGeometryStorage::__ct (vapourRT:vfGeometryStorage.C)
     10  0.01s(  0.0)   23s( 99.7) IM_ShortArrayToFrame (vapourRT:utilities.C)
     10  0.01s(  0.0)   23s( 99.8)      _sem_init (/usr/lib32/libc.so.1:sem_open.c)
     10  0.01s(  0.0)   23s( 99.8) pfGeoSet::__ct (/usr/lib32/libpf_ogl.so:../../../lib/libpr/pfGeoSet.C)
      6 0.006s(  0.0)   23s( 99.9) sdbPrimitive::app (vapourRT:sdbPrimitive.C)
      6 0.006s(  0.0)   23s( 99.9)       mapClock (/usr/lib32/libpf_ogl.so:../../../lib/libpr/time.C)
      2 0.002s(  0.0)   23s( 99.9)       _amalloc (/usr/lib32/libc.so.1:amalloc.c)
      2 0.002s(  0.0)   23s( 99.9) img_rle_expand (vapourRT:rle.c)
      2 0.002s(  0.0)   23s( 99.9) _mips2_test_then_add32 (/usr/lib32/libc.so.1:/xlv24/patches/2463/work/irix/lib/libc/libc_n32_M4/mp/libmutexs.s)
      2 0.002s(  0.0)   23s( 99.9) pfMemory::getMemory (/usr/lib32/libpf_ogl.so:../../../lib/libpr/pfMemory.C)




SSRUN OUTPUT - APP THREAD/PERFORMER 2.1
=======================================

-------------------------------------------------------------------------------
Profile listing generated Mon May 25 21:54:26 1998
    with:	prof vapourRT vapourRT.fpcsampx.11282 
-------------------------------------------------------------------------------

samples   time    CPU    FPU   Clock   N-cpu  S-interval Countsize
  54657    55s R10000 R10010 195.0MHz   1      1.0ms     4(bytes)

Each sample covers 4 bytes for every  1.0ms ( 0.00% of 54.6570s)


-------------------------------------------------------------------------------
  -p[rocedures] using pc-sampling.
  Sorted in descending order by the number of samples in each procedure.
  Unexecuted procedures are excluded.
-------------------------------------------------------------------------------

samples   time(%)      cum time(%)      procedure (dso:file)

  19921    20s( 36.4)   20s( 36.4)        _sginap (/usr/lib32/libc.so.1:/xlv24/patches/2463/work/irix/lib/libc/libc_n32_M4/sys/sginap.s)
   6024     6s( 11.0)   26s( 47.5) pfList::search (/usr/lib32/libpf_ogl.so:/perf7/zhz/perftot1/perf/lib/libpr/pfList.C)
   4249   4.2s(  7.8)   30s( 55.2) sdbPrimitive::app (vapourRT:sdbPrimitive.C)
   2431   2.4s(  4.4)   33s( 59.7)          _read (/usr/lib32/libc.so.1:/xlv24/patches/2463/work/irix/lib/libc/libc_n32_M4/sys/read.s)
   1326   1.3s(  2.4)   34s( 62.1) pfGeoState::setAttr (/usr/lib32/libpf_ogl.so:/perf7/zhz/perftot1/perf/lib/libpr/pfGeoState.C)
   1297   1.3s(  2.4)   35s( 64.5) _r4kmp_setlock (/usr/lib32/libc.so.1:/xlv24/patches/2463/work/irix/lib/libc/libc_n32_M4/mp/r4k.s)
   1178   1.2s(  2.2)   36s( 66.6)         _ioctl (/usr/lib32/libc.so.1:/xlv24/patches/2463/work/irix/lib/libc/libc_n32_M4/sys/ioctl.s)
   1052   1.1s(  1.9)   37s( 68.6)     pfSCS::app (/usr/lib32/libpf_ogl.so:/perf7/zhz/perftot1/perf/lib/libpf/pfSCS.C)
   1049     1s(  1.9)   39s( 70.5)     getzoomrow (vapourRT:imresize.C)
   1030     1s(  1.9)   40s( 72.4) pfGeoState::setMode (/usr/lib32/libpf_ogl.so:/perf7/zhz/perftot1/perf/lib/libpr/pfGeoState.C)
    748  0.75s(  1.4)   40s( 73.7) pfCycleBuffer::changed (/usr/lib32/libpf_ogl.so:/perf7/zhz/perftot1/perf/lib/libpr/pfCycleBuffer.C)
    709  0.71s(  1.3)   41s( 75.0) pfList::fastRemove (/usr/lib32/libpf_ogl.so:/perf7/zhz/perftot1/perf/lib/libpr/pfList.C)
    624  0.62s(  1.1)   42s( 76.2) pfMatrix::preMult (/usr/lib32/libpf_ogl.so:/perf7/zhz/perftot1/perf/lib/libpr/pfLinMath.C)
    598   0.6s(  1.1)   42s( 77.3)     applyxfilt (vapourRT:imresize.C)
    567  0.57s(  1.0)   43s( 78.3) IM_ShortArrayToFrame (vapourRT:utilities.C)
    535  0.54s(  1.0)   43s( 79.3)  pfMemory::ref (/usr/lib32/libpf_ogl.so:/perf7/zhz/perftot1/perf/lib/libpr/pfMemory.C)




PAR OUTPUT - APP THREAD/PERFORMER 2.2
=====================================

    0mS[ 1]vapourRT_IP27_6.(18339): ioctl(24, RRM_GETVSYNC, 0x7fff29d0) = 0
    0mS[ 1]vapourRT_IP27_6.(18339): ioctl(12, UIOCUNBLOCK, 0x47c6) = 0
    0mS[ 1]vapourRT_IP27_6.(18339): ioctl(12, UIOCBLOCK, 0xc) = 0
   11mS[ 1]vapourRT_IP27_6.(18339): ioctl(29, SIOCNREAD, 0x7fff20c0) = 0
   11mS[ 1]vapourRT_IP27_6.(18339): ioctl(30, 0x786301, 0x4) = 0
   11mS[ 1]vapourRT_IP27_6.(18339): read(29, 0x7fff27f0, 32) errno = 11 (Resource temporarily unavailable)
   11mS[ 1]vapourRT_IP27_6.(18339): select(30, IN:set=29 OUT:set=29, 0, 0, 0) = 1
   12mS[ 1]vapourRT_IP27_6.(18339): read(29, <01 01 c6 fd 00 00 00 00 01 40 00 fe 00 9c 00 96>..., 32) = 32
   12mS[ 1]vapourRT_IP27_6.(18339): ioctl(30, 0x786301, 0x4) = 0
   12mS[ 1]vapourRT_IP27_6.(18339): read(29, 0x7fff2830, 32) errno = 11 (Resource temporarily unavailable)
   12mS[ 1]vapourRT_IP27_6.(18339): select(30, IN:set=29 OUT:set=29, 0, 0, 0) = 1
   12mS[ 1]vapourRT_IP27_6.(18339): read(29, <01 08 c6 fe 00 00 00 00 00 00 00 a1 00 00 00 00>..., 32) = 32
   12mS[ 1]vapourRT_IP27_6.(18339): ioctl(30, 0x786301, 0x4) = 0
   12mS[ 1]vapourRT_IP27_6.(18339): read(29, 0x7fff26d0, 32) errno = 11 (Resource temporarily unavailable)
   12mS[ 1]vapourRT_IP27_6.(18339): select(30, IN:set=29 OUT:set=29, 0, 0, 0) = 1
   13mS[ 1]vapourRT_IP27_6.(18339): read(29, <01 01 c7 00 00 00 00 00 01 40 00 fe 00 9c 00 96>..., 32) = 32
   13mS[ 1]vapourRT_IP27_6.(18339): ioctl(24, RRM_GETVSYNC, 0x7fff2a10) = 0
   13mS[ 1]vapourRT_IP27_6.(18339): ioctl(24, RRM_WAITVSYNC, 0x7fff29d0) = 0
   17mS[ 1]vapourRT_IP27_6.(18339): ioctl(24, RRM_GETVSYNC, 0x7fff29d0) = 0
   17mS[ 1]vapourRT_IP27_6.(18339): ioctl(12, UIOCUNBLOCK, 0x47c6) = 0
   17mS[ 1]vapourRT_IP27_6.(18339): ioctl(12, UIOCBLOCK, 0xc) = 0
   28mS[ 1]vapourRT_IP27_6.(18339): ioctl(29, SIOCNREAD, 0x7fff20c0) = 0
   28mS[ 1]vapourRT_IP27_6.(18339): ioctl(24, RRM_GETVSYNC, 0x7fff2a10) = 0
   28mS[ 1]vapourRT_IP27_6.(18339): ioctl(24, RRM_WAITVSYNC, 0x7fff29d0) = 0
   34mS[ 1]vapourRT_IP27_6.(18339): ioctl(24, RRM_GETVSYNC, 0x7fff29d0) = 0
   34mS[ 1]vapourRT_IP27_6.(18339): ioctl(12, UIOCUNBLOCK, 0x47c6) = 0
   34mS[ 1]vapourRT_IP27_6.(18339): ioctl(12, UIOCBLOCK, 0xc) = 0
   44mS[ 1]vapourRT_IP27_6.(18339): ioctl(29, SIOCNREAD, 0x7fff20c0) = 0
   45mS[ 1]vapourRT_IP27_6.(18339): ioctl(24, RRM_GETVSYNC, 0x7fff2a10) = 0
   45mS[ 1]vapourRT_IP27_6.(18339): ioctl(24, RRM_WAITVSYNC, 0x7fff29d0) = 0
   50mS[ 1]vapourRT_IP27_6.(18339): ioctl(24, RRM_GETVSYNC, 0x7fff29d0) = 0
   51mS[ 1]vapourRT_IP27_6.(18339): ioctl(12, UIOCUNBLOCK, 0x47c6) = 0
   51mS[ 1]vapourRT_IP27_6.(18339): ioctl(12, UIOCBLOCK, 0xc) = 0
   61mS[ 1]vapourRT_IP27_6.(18339): ioctl(29, SIOCNREAD, 0x7fff20c0) = 0
   61mS[ 1]vapourRT_IP27_6.(18339): ioctl(24, RRM_GETVSYNC, 0x7fff2a10) = 0
   61mS[ 1]vapourRT_IP27_6.(18339): ioctl(24, RRM_WAITVSYNC, 0x7fff29d0) = 0
   67mS[ 1]vapourRT_IP27_6.(18339): ioctl(24, RRM_GETVSYNC, 0x7fff29d0) = 0
   67mS[ 1]vapourRT_IP27_6.(18339): ioctl(12, UIOCUNBLOCK, 0x47c6) = 0
   67mS[ 1]vapourRT_IP27_6.(18339): ioctl(12, UIOCBLOCK, 0xc) = 0
   78mS[ 1]vapourRT_IP27_6.(18339): ioctl(29, SIOCNREAD, 0x7fff20c0) = 0
   78mS[ 1]vapourRT_IP27_6.(18339): ioctl(30, 0x786301, 0x4) = 0
   78mS[ 1]vapourRT_IP27_6.(18339): read(29, 0x7fff27f0, 32) errno = 11 (Resource temporarily unavailable)
   78mS[ 1]vapourRT_IP27_6.(18339): select(30, IN:set=29 OUT:set=29, 0, 0, 0) = 1
   78mS[ 1]vapourRT_IP27_6.(18339): read(29, <01 01 c7 01 00 00 00 00 01 40 00 fe 00 9c 00 96>..., 32) = 32
   78mS[ 1]vapourRT_IP27_6.(18339): ioctl(30, 0x786301, 0x4) = 0
   78mS[ 1]vapourRT_IP27_6.(18339): read(29, 0x7fff2830, 32) errno = 11 (Resource temporarily unavailable)
   78mS[ 1]vapourRT_IP27_6.(18339): select(30, IN:set=29 OUT:set=29, 0, 0, 0) = 1
   79mS[ 1]vapourRT_IP27_6.(18339): read(29, <01 08 c7 02 00 00 00 00 00 00 00 a1 00 00 00 00>..., 32) = 32
   79mS[ 1]vapourRT_IP27_6.(18339): ioctl(30, 0x786301, 0x4) = 0
   79mS[ 1]vapourRT_IP27_6.(18339): read(29, 0x7fff26d0, 32) errno = 11 (Resource temporarily unavailable)
   79mS[ 1]vapourRT_IP27_6.(18339): select(30, IN:set=29 OUT:set=29, 0, 0, 0) = 1
   79mS[ 1]vapourRT_IP27_6.(18339): read(29, <01 01 c7 04 00 00 00 00 01 40 00 fe 00 9c 00 96>..., 32) = 32


FILE DESCRIPTOR 29-30

 1444mS[ 3]vapourRT_IP27_6.(18552): open(/dev/xconnc, O_RDWR, 021) = 29
 2969mS[ 0]vapourRT_IP27_6.(18569): open(/dev/xconnc, O_RDWR, 021) = 29
 2970mS[ 0]vapourRT_IP27_6.(18569): open(/var/tmp/.Xsgishm/cli26-18569.map, O_RDWR|O_CREAT|O_EXCL, 0600) = 30




PAR OUTPUT - APP THREAD/PERFORMER 2.1
=====================================

    0mS[ 1]vapourRT_IP27_6.(11700): ioctl(24, RRM_GETVSYNC, 0x7fff29d0) = 0
    0mS[ 1]vapourRT_IP27_6.(11700): ioctl(12, UIOCUNBLOCK, 0x2db6) = 0
    0mS[ 1]vapourRT_IP27_6.(11700): ioctl(12, UIOCBLOCK, 0xc) = 0
    8mS[ 1]vapourRT_IP27_6.(11700): ioctl(29, SIOCNREAD, 0x7fff2090) = 0
    8mS[ 1]vapourRT_IP27_6.(11700): ioctl(24, RRM_GETVSYNC, 0x7fff2a00) = 0
    8mS[ 1]vapourRT_IP27_6.(11700): ioctl(24, RRM_WAITVSYNC, 0x7fff29d0) = 0
   16mS[ 1]vapourRT_IP27_6.(11700): ioctl(24, RRM_GETVSYNC, 0x7fff29d0) = 0
   16mS[ 1]vapourRT_IP27_6.(11700): ioctl(12, UIOCUNBLOCK, 0x2db6) = 0
   17mS[ 1]vapourRT_IP27_6.(11700): ioctl(12, UIOCBLOCK, 0xc) = 0
   25mS[ 1]vapourRT_IP27_6.(11700): ioctl(29, SIOCNREAD, 0x7fff2090) = 0
   25mS[ 1]vapourRT_IP27_6.(11700): ioctl(24, RRM_GETVSYNC, 0x7fff2a00) = 0
   25mS[ 1]vapourRT_IP27_6.(11700): ioctl(24, RRM_WAITVSYNC, 0x7fff29d0) = 0
   33mS[ 1]vapourRT_IP27_6.(11700): ioctl(24, RRM_GETVSYNC, 0x7fff29d0) = 0
   33mS[ 1]vapourRT_IP27_6.(11700): ioctl(12, UIOCUNBLOCK, 0x2db6) = 0
   33mS[ 1]vapourRT_IP27_6.(11700): ioctl(12, UIOCBLOCK, 0xc) = 0
   42mS[ 1]vapourRT_IP27_6.(11700): ioctl(29, SIOCNREAD, 0x7fff2090) = 0
   42mS[ 1]vapourRT_IP27_6.(11700): ioctl(24, RRM_GETVSYNC, 0x7fff2a00) = 0
   42mS[ 1]vapourRT_IP27_6.(11700): ioctl(24, RRM_WAITVSYNC, 0x7fff29d0) = 0
   50mS[ 1]vapourRT_IP27_6.(11700): ioctl(24, RRM_GETVSYNC, 0x7fff29d0) = 0
   50mS[ 1]vapourRT_IP27_6.(11700): ioctl(12, UIOCUNBLOCK, 0x2db6) = 0
   50mS[ 1]vapourRT_IP27_6.(11700): ioctl(12, UIOCBLOCK, 0xc) = 0
   58mS[ 1]vapourRT_IP27_6.(11700): ioctl(29, SIOCNREAD, 0x7fff2090) = 0
   58mS[ 1]vapourRT_IP27_6.(11700): ioctl(24, RRM_GETVSYNC, 0x7fff2a00) = 0
   58mS[ 1]vapourRT_IP27_6.(11700): ioctl(24, RRM_WAITVSYNC, 0x7fff29d0) = 0
   66mS[ 1]vapourRT_IP27_6.(11700): ioctl(24, RRM_GETVSYNC, 0x7fff29d0) = 0
   66mS[ 1]vapourRT_IP27_6.(11700): ioctl(12, UIOCUNBLOCK, 0x2db6) = 0
   67mS[ 1]vapourRT_IP27_6.(11700): ioctl(12, UIOCBLOCK, 0xc) = 0
   75mS[ 1]vapourRT_IP27_6.(11700): ioctl(29, SIOCNREAD, 0x7fff2090) = 0




DBX OUTPUT - APP THREAD/PERFORMER 2.2
=====================================

BREAKPOINT IN _read within idle loop:

>  0 _read(0x1d, 0x7fff27f0, 0x20, 0x0, 0xf7f1b40, 0x1, 0x10344578, 0x10) ["/xlv24/patches/2463/work/irix/lib/libc/libc_n32_M4/sys/read.s":15, 0xfac5860 (pixie 0xfa38068)]
   1 _X11TransShmBufRead(0x1d, 0x7fff27f0, 0x20, 0x0, 0xf7f1b40, 0x1, 0x10344578, 0x10) ["/xlv23/patches/2880/work/x/xc/lib/xtrans/XtransShmBuf.c":1727, 0xf749044 (pixie 0xf7a3af4)]
   2 _X11TransRead(0x1d, 0x7fff27f0, 0x20, 0x0, 0xf7f1b40, 0x1, 0x10344578, 0x10) ["/xlv23/patches/2880/work/x/xc/lib/xtrans/Xtrans.c":917, 0xf749cb4 (pixie 0xf7a4764)]
   3 _XRead(0x103b5518, 0x7fff27f0, 0x20, 0x0, 0xf7f1b40, 0x1, 0x10344578, 0x10) ["/xlv23/patches/2880/work/x/xc/lib/X11/XlibInt.c":1146, 0xf72f6ec (pixie 0xf70b184)]
   4 _XReply(0x103b5518, 0x7fff27f0, 0x0, 0x0, 0xf7f1b40, 0x1, 0x10344578, 0x10) ["/xlv23/patches/2880/work/x/xc/lib/X11/XlibInt.c":1896, 0xf7306e8 (pixie 0xf70c180)]
   5 XTranslateCoordinates(0x103b5518, 0x5000004, 0x20, 0x0, 0x0, 0x0, 0x0, 0x0) ["/xlv23/patches/2880/work/x/xc/lib/X11/TrCoords.c":49, 0xf72cb34 (pixie 0xf70cdd8)]
   6 pfWindow::pr_updateScreenOrigin(_XDisplay*)(0x6404fb60, 0x7fff27f0, 0x20, 0x0, 0xf7f1b40, 0x1, 0x10344578, 0x10) ["/build/perfbuild/perftot0/perf/lib/libpr/pfWindow.C":4941, 0x5b292e48 (pixie 0x5b292e48)]
   7 pfPipeWindow::pf_updateWindowOriginSize(void)(0x64045b50, 0x0, 0x20, 0x0, 0xf7f1b40, 0x1, 0x10344578, 0x10) ["/build/perfbuild/perftot0/perf/lib/libpf/pfPipeWindow.C":1377, 0x5b140eac (pixie 0x5b140eac)]
   8 pfPipeWindow::pf_updateWindow(void)(0x64045b50, 0x7fff27f0, 0x20, 0x0, 0xf7f1b40, 0x1, 0x10344578, 0x10) ["/build/perfbuild/perftot0/perf/lib/libpf/pfPipeWindow.C":1197, 0x5b14098c (pixie 0x5b14098c)]
   9 ::updatePWins(void)(0x1d, 0x0, 0x1, 0x0, 0xf7f1b40, 0x1, 0x10344578, 0x10) ["/build/perfbuild/perftot0/perf/lib/libpf/pfProcess.C":3375, 0x5b192ae4 (pixie 0x5b192ae4)]
   10 ::pfSync(0x1d, 0x7fff27f0, 0x20, 0x0, 0xf7f1b40, 0x1, 0x10344578, 0x10) ["/build/perfbuild/perftot0/perf/lib/libpf/pfProcess.C":3468, 0x5b192e84 (pixie 0x5b192e84)]
   11 ::vfLaunchRenderingEngine(unsigned int,bool)(id = 0, foreground = '') ["/vobs/waipa/runtime/renderingEngine/main/vfRenderingEngine.C":225, 0x100b7548 (pixie 0x100b7548)]


BREAKPOINT IN _select within idle loop:

>  0 _select(0x1e, 0x7fff2660, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) ["/xlv24/patches/2463/work/irix/lib/libc/libc_n32_M4/sys/select.s":12, 0xfac59b0 (pixie 0xfa3d41c)]
   1 _XWaitForReadable(0x103b5518, 0x1d, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) ["/xlv23/patches/2880/work/x/xc/lib/X11/XlibInt.c":491, 0xf72ebb4 (pixie 0xf70a64c)]
   2 _XRead(0x103b5518, 0x7fff2830, 0x20, 0x0, 0x0, 0x0, 0x0, 0x0) ["/xlv23/patches/2880/work/x/xc/lib/X11/XlibInt.c":1154, 0xf72f748 (pixie 0xf70b1e0)]
   3 _XReply(0x103b5518, 0x7fff2830, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) ["/xlv23/patches/2880/work/x/xc/lib/X11/XlibInt.c":1896, 0xf7306e8 (pixie 0xf70c180)]
   4 XGetGeometry(0x103b5518, 0x7fff2660, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) ["/xlv23/patches/2880/work/x/xc/lib/X11/GetGeom.c":43, 0xf7147d8 (pixie 0xf70cf0c)]
   5 pfPipeWindow::pf_updateWindowOriginSize(void)(0x64045b50, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) ["/build/perfbuild/perftot0/perf/lib/libpf/pfPipeWindow.C":1378, 0x5b140edc (pixie 0x5b140edc)]
   6 pfPipeWindow::pf_updateWindow(void)(0x64045b50, 0x7fff2660, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) ["/build/perfbuild/perftot0/perf/lib/libpf/pfPipeWindow.C":1197, 0x5b14098c (pixie 0x5b14098c)]
   7 ::updatePWins(void)(0x1e, 0x0, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0) ["/build/perfbuild/perftot0/perf/lib/libpf/pfProcess.C":3375, 0x5b192ae4 (pixie 0x5b192ae4)]
   8 ::pfSync(0x1e, 0x7fff2660, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) ["/build/perfbuild/perftot0/perf/lib/libpf/pfProcess.C":3468, 0x5b192e84 (pixie 0x5b192e84)]
   9 ::vfLaunchRenderingEngine(unsigned int,bool)(id = 0, foreground = '') ["/vobs/waipa/runtime/renderingEngine/main/vfRenderingEngine.C":225, 0x100b7548 (pixie 0x100b7548)]




DBX OUTPUT - APP THREAD/PERFORMER 2.1
=====================================

>  0 pfPipeWindow::pf_updateWindow(void)(0x64048060, 0x0, 0x0, 0x0, 0xf7f1b48, 0x7fff2098, 0x20000000, 0x1) ["/perf7/zhz/perftot1/perf/lib/libpf/pfPipeWindow.C":843, 0x5c000fd0 (pixie 0x5c000fd0)]
   1 ::updatePWins(void)(0x64048060, 0x0, 0x0, 0x0, 0xf7f1b48, 0x7fff2098, 0x20000000, 0x1) ["/perf7/zhz/perftot1/perf/lib/libpf/pfProcess.C":2057, 0x5c07a488 (pixie 0x5c07a488)]
   2 ::pfSync(0x64048060, 0x0, 0x0, 0x0, 0xf7f1b48, 0x7fff2098, 0x20000000, 0x1) ["/perf7/zhz/perftot1/perf/lib/libpf/pfProcess.C":2138, 0x5c07a738 (pixie 0x5c07a738)]
   3 ::vfLaunchRenderingEngine(unsigned int,bool)(id = 0, foreground = '') ["/vobs/waipa/runtime/renderingEngine/main/vfRenderingEngine.C":220, 0x100b5f88 (pixie 0x100b5f88)]





--PART-BOUNDARY=.19805270952.ZM28081.atlantis--

=======================================================================
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 May 27 08:53:14 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id IAA14250 for info-performer-dist@holodeck.engr.sgi.com; Wed, 27 May 1998 08:34:45 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id IAA14223 for <info-performer@holodeck.engr.sgi.com>; Wed, 27 May 1998 08:34:44 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id IAA69516
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 27 May 1998 08:34:43 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from quid.csd.sgi.com ([150.166.129.99]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA28375
	for <info-performer@sgi.com>; Wed, 27 May 1998 08:34:42 -0700 (PDT)
	mail_from (robj@quid.csd.sgi.com)
Received: (from robj@localhost) by quid.csd.sgi.com (980205.SGI.8.8.8/960327.SGI.AUTOCF) id IAA26903; Wed, 27 May 1998 08:29:22 -0700 (PDT)
From: "Rob Jenkins" <robj@quid.csd.sgi.com>
Message-Id: <9805270829.ZM26588@quid.csd.sgi.com>
Date: Wed, 27 May 1998 08:29:21 -0700
In-Reply-To: "Ballard Andrews; (4/28/98)" <andrews@ridgefield.sdr.slb.com>
        "Bug" (May 26,  5:16pm)
References: <356B312F.2781@ridgefield.sdr.slb.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: "Ballard Andrews; (4/28/98)" <andrews@ridgefield.sdr.slb.com>,
        info-performer@sgi.com
Subject: Re: Bug
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On May 26,  5:16pm, Ballard Andrews; (4/28/98) wrote:
> Subject: Bug
> On an Indigo running 6.2 and Peformer 2.0
> I have encounterd a strange bug with pfSequence;
> If I substitute a pfSwitch node in the hierarchy
> I don't have a problem and the code runs fine.
> The fault appears to lie with the call to pfGetSeqFrame.
> The same thing happens in my C++ version.
> I recall there were some really BIG patch sets I used
> to have on my RE running 6.2 and my IR running 6.4
> (the same code worked find on these machines),
> but I forgot the numbers.
>

The platform patches will be very different for all those machines, it would be
worth you making sure you have the latest patch sets for each platform ( esp
the Indigo with the problem ), patchset info can be found off:
http://www.sgi.com/support/
The performer patches for pf 2.0 are described in the pf FAQs ( you'd need 1696
and 1392 for a 6.2 machine ), unless you can upgrade to pf 2.2

>  0 pfSequence::nb_getFrame(int*) const(0x1807c400, 0x0, 0x1badbebe,
> 0x5f854664) ["../../../lib/libpf/pfSequence.C":287, 0x5e9261bc]
>    1 pfGetSeqFrame(0x1807c400, 0x0, 0x1badbebe, 0x5f854664)
> ["../../../lib/libpf/cSequence.C":181, 0x5e937204]
>    2 main(0x2, 0x7fff2f54, 0x1badbebe, 0x5f854664) ["../bnl.c":607,
> 0x40500c]
>    3 __istart() ["crt1tinit.s":13, 0x403a30]
>

The 0x1badbebe is a pattern that Performer uses to highlight bad memory values
of some sort, that doesn't help diagnose the problem much though, if you could
double check patches then boil down to the shortest test case possible if it
fails, then please post that ( and log a support call ).

Cheers
Rob

> B. Andrews
> =======================================================================
> 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 Ballard Andrews; (4/28/98)



-- 
________________________________________________________________
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 May 27 09:46:28 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA14488 for info-performer-dist@holodeck.engr.sgi.com; Wed, 27 May 1998 09:35:47 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA14461 for <info-performer@holodeck.engr.sgi.com>; Wed, 27 May 1998 09:35:46 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA68346
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 27 May 1998 09:35:45 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA25292
	for <info-performer@sgi.com>; Wed, 27 May 1998 09:35:44 -0700 (PDT)
	mail_from (shankar.n.swamy@boeing.com)
Received: from mercury.boeing.com ([130.42.138.11])
	by mailgate2.boeing.com (8.8.5/8.8.5) with SMTP id JAA26864
	for <info-performer@sgi.com>; Wed, 27 May 1998 09:35:41 -0700 (PDT)
Received: from redwood.rt.cs.boeing.com by mercury.boeing.com; Wed, 27 May 98 09:35:40 -0700
Received: from vidya by redwood.rt.cs.boeing.com (5.x/SMI-SVR4)
	id AA02364; Wed, 27 May 1998 09:36:30 -0700
Sender: shankar@boeing.com
Message-Id: <356C40D6.6488@boeing.com>
Date: Wed, 27 May 1998 09:35:34 -0700
From: Shankar N Swamy <shankar.n.swamy@boeing.com>
Organization: Applied Research & Technology, Boeing
X-Mailer: Mozilla 3.04C-SGI (X11; I; IRIX64 6.4 IP30)
Mime-Version: 1.0
To: Performer Mailing List <info-performer@sgi.com>
Subject: getUserData(), setUserData(...) problem in pf 2.2 ...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Hello PfWorld!


I recompiled a  program under 2.2 and it is failing at 
::getUserData() call.  This call is returning a 
NULL pointer.  This program works fine with earlier 
version of pf.

I there a patch that I am missing?  Can some PfPerson help, 
please.

Thanks.

Sincerely,

shankar swamy
-------------------------------------------------------------------
shankar.n.swamy@boeing.com           Shankar N. Swamy
                                     Boeing Research and Technology 
PHONE: (425) 865-4286                Virtual Systems Group,
FAX  : (425) 865-2965                PO Box 3707 MS 7L-48,
                                     Seattle, WA 98124-2207.
--------------------------------------------------------------------
=======================================================================
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 May 27 11:51:04 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA15233 for info-performer-dist@holodeck.engr.sgi.com; Wed, 27 May 1998 11:38:05 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA15206 for <info-performer@holodeck.engr.sgi.com>; Wed, 27 May 1998 11:38:04 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA58218
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 27 May 1998 11:38:03 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id LAA14379
	for <info-performer@sgi.com>; Wed, 27 May 1998 11:38:02 -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 LAA15988; Wed, 27 May 1998 11:37:57 -0700
Date: Wed, 27 May 1998 11:37:57 -0700
From: src@rose.engr.sgi.com (Sharon Clay)
Message-Id: <9805271137.ZM15986@rose.engr.sgi.com>
In-Reply-To: Shankar N Swamy <shankar.n.swamy@boeing.com>
        "getUserData(), setUserData(...) problem in pf 2.2 ..." (May 27,  9:35am)
References: <356C40D6.6488@boeing.com>
X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail)
To: Shankar N Swamy <shankar.n.swamy@boeing.com>,
        Performer Mailing List <info-performer@sgi.com>
Subject: Re: getUserData(), setUserData(...) problem in pf 2.2 ...
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

+>---- On May 27,  9:35am, Shankar N Swamy wrote:
> Subject: getUserData(), setUserData(...) problem in pf 2.2 ...
->From guest@holodeck  Wed May 27 09:46:51 1998
->Sender: shankar@boeing.com
->Date: Wed, 27 May 1998 09:35:34 -0700
->From: Shankar N Swamy <shankar.n.swamy@boeing.com>
->Organization: Applied Research & Technology, Boeing
->X-Mailer: Mozilla 3.04C-SGI (X11; I; IRIX64 6.4 IP30)
->To: Performer Mailing List <info-performer@sgi.com>
->Subject: getUserData(), setUserData(...) problem in pf 2.2 ...
->
->Hello PfWorld!
->
->I recompiled a  program under 2.2 and it is failing at 
->::getUserData() call.  This call is returning a 
->NULL pointer.  This program works fine with earlier 
->version of pf.
->
->I there a patch that I am missing?  Can some PfPerson help, 
->please.

We don't know of any bugs with user data and I am afraid that this isn't
enough yet to tell you any more....
A smalll test case would obviously help a lot and it would be great if you could
file that with our hot-line.

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  Wed May 27 13:08:03 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA15548 for info-performer-dist@holodeck.engr.sgi.com; Wed, 27 May 1998 13:00:51 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id NAA15521 for <info-performer@holodeck.engr.sgi.com>; Wed, 27 May 1998 13:00:49 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA91038
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 27 May 1998 13:00:49 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from acusoft.com (acusoft.acusoft.com [205.187.235.130]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id NAA15143
	for <info-performer@sgi.com>; Wed, 27 May 1998 13:00:46 -0700 (PDT)
	mail_from (miller@acusoft.com)
Received: from marvin by acusoft.com (5.x/SMI-SVR4)
	id AA06422; Wed, 27 May 1998 16:00:22 -0400
Received: by marvin (950413.SGI.8.6.12) id QAA19778; Wed, 27 May 1998 16:00:22 -0400
Date: Wed, 27 May 1998 16:00:22 -0400 (EDT)
From: "Thomas M. Miller" <miller@acusoft.com>
X-Sender: miller@marvin
To: Sharon Clay <src@rose.engr.sgi.com>
Cc: Shankar N Swamy <shankar.n.swamy@boeing.com>,
        Performer Mailing List <info-performer@sgi.com>
Subject: Re: getUserData(), setUserData(...) problem in pf 2.2 ...
In-Reply-To: <9805271137.ZM15986@rose.engr.sgi.com>
Message-Id: <Pine.SGI.3.91.980527155156.18249B-100000@marvin>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O


On Wed, 27 May 1998, Sharon Clay wrote:

> ->Hello PfWorld!
> ->
> ->I recompiled a  program under 2.2 and it is failing at 
> ->::getUserData() call.  This call is returning a 
> ->NULL pointer.  This program works fine with earlier 
> ->version of pf.
> ->
> ->I there a patch that I am missing?  Can some PfPerson help, 
> ->please.

I had the same problem. I found that they changed the userDataCall
from ::getUserData( void ) to ::getUserData( int ).With similar
things done  to ::setUserData to support a list of user data.

getUserData( void ) was left as an inline function that calls
getUserData( 0 ). 

setUserData( void * ) was left as an inline fuction calling
setUserData( 0, void *).

I changed all of my setUserData calls and getUserData calls
so that I don't have to go through the inline fuction.  Then
I got my user data pointers back.




=======================================================================
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 May 27 16:43:34 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA16092 for info-performer-dist@holodeck.engr.sgi.com; Wed, 27 May 1998 16:32:41 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id QAA16065 for <info-performer@holodeck.engr.sgi.com>; Wed, 27 May 1998 16:32:40 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id QAA87891
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 27 May 1998 16:32:40 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from lobotomy.evt.com ([204.133.157.33]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id QAA09278
	for <info-performer@sgi.com>; Wed, 27 May 1998 16:32:38 -0700 (PDT)
	mail_from (herod@evt.com)
Received: from evt.com (localhost [127.0.0.1]) by lobotomy.evt.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA12778 for <info-performer@sgi.com>; Wed, 27 May 1998 17:32:37 -0600
Sender: herod@evt.com
Message-ID: <356CA294.7F5A1DBE@evt.com>
Date: Wed, 27 May 1998 17:32:36 -0600
From: Scott Herod <herod@evt.com>
X-Mailer: Mozilla 4.05 [en] (X11; I; IRIX 6.3 IP32)
MIME-Version: 1.0
To: info-performer@sgi.com
Subject: Elusive texture memory problem
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Are there any known problems with performer (or gl) paging
textures back and forth between hardware texture memory?
(Performer 2.0.4)  In particular, we've got a performer scene
with multiple small textures created from raster images.  If
we repeatedly play the scene, it runs fine for ~30 times (not
always the same number) and then one texture replaces another.

    I've seen the problem occur between separate scenes, and
it has been reported that once a Doom texture appeared where
it couldn't possibly be created.  (Fortunately not on my machine.)

    I have a lot of ideas as to what the problem is not...
We're not confusing our pointers to the beginnings of the 
raster images.  pfDelete is called religiously.  We are not
opening files of raster images.

    I have only seen textures replace those (supposedly) created
later, never the other way around.  I've only seen textures
be replaced by similar sized textures.

    The pfuClearTextureMemory() routine which is part of 
pfuTextureMemory corrects the problem with some scenes if it
is called after the scene is deleted but it does not effect
other examples.

    Any suggestions of other places to look would be greatly
appreciated.

Scott Herod
herod@evt.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 May 27 17:41:28 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id RAA16359 for info-performer-dist@holodeck.engr.sgi.com; Wed, 27 May 1998 17:25:19 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id RAA16332 for <info-performer@holodeck.engr.sgi.com>; Wed, 27 May 1998 17:25:18 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id RAA72811
	for <info-performer@cthulhu.engr.sgi.com>;
	Wed, 27 May 1998 17:25:17 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id RAA27580
	for <info-performer@sgi.com>; Wed, 27 May 1998 17:25:15 -0700 (PDT)
	mail_from (kbrussel@media.mit.edu)
Received: from ongar.media.mit.edu (ongar.media.mit.edu [18.85.16.82])
	by aleve.media.mit.edu (8.8.7/ML970927) with ESMTP id UAA01189;
	Wed, 27 May 1998 20:25:14 -0400 (EDT)
Received: (from kbrussel@localhost) by ongar.media.mit.edu (8.8.6/8.7.3) id UAA13296; Wed, 27 May 1998 20:25:14 -0400 (EDT)
Date: Wed, 27 May 1998 20:25:14 -0400 (EDT)
Message-Id: <199805280025.UAA13296@ongar.media.mit.edu>
From: Kenneth B Russell <kbrussel@media.mit.edu>
To: Performer Enthusiasts <info-performer@sgi.com>
Subject: More shadow bug info
Reply-to: kbrussel@media.mit.edu
Status: O


Hi Performers,

Here's some more information on what appears to be an iR bug with
hardware shadows. I have a call logged with support, but don't
think a bug has been filed yet by my assigned engineer. Anyway,
since the last email I have run this test case on two iR machines
and an old Onyx with RealityEngine graphics (and IrisGL shadows).
The bug occurs on both the iR machines but, significantly, NOT on
the RE. So clearly this is a new problem and hopefully therefore
can be fixed.

A quick summary: to demonstrate the problem you need to have a
machine with infiniteReality graphics and the Performer 2.2
distribution. cd to /tmp and do the following:

cc -n32 -o shadows /usr/share/Performer/src/pguide/libpf/C/shadows.c \
-lpf -lpfdu -lpfutil -lX11 -lGL -lGLU -limage -lm

then "shadows stool.flt" will bring up a chair with shadows
underneath it. There are two "glitches" during the light source's
360 degree animation cycle where the shadow appears to be
replaced with a big polygon. This bug looks exactly like what I'm
seeing in my Performer application, which uses shadows in a
similar way.

Could someone from SGI let me know whether this problem is
reproducible internally? We recently patched our Onyx2 up to the
May patch set and that didn't solve the problem.

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  Thu May 28 01:18:05 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id BAA18800 for info-performer-dist@holodeck.engr.sgi.com; Thu, 28 May 1998 01:05:57 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id BAA18773 for <info-performer@holodeck.engr.sgi.com>; Thu, 28 May 1998 01:05:56 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id BAA41930
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 28 May 1998 01:05:55 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id BAA13761; Thu, 28 May 1998 01:05:54 -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 BAA27356; Thu, 28 May 1998 01:05:49 -0700
Date: Thu, 28 May 1998 01:05:49 -0700
From: src@rose.engr.sgi.com (Sharon Clay)
Message-Id: <9805280105.ZM27354@rose.engr.sgi.com>
In-Reply-To: "Jean-Luc Dery" <dery@discreet.com>
        "Performance problem with PF 2.2" (May 27,  9:52am)
References: <9805270952.ZM28081@atlantis>
X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail)
To: "Jean-Luc Dery" <dery@discreet.com>, Amit_Parghi@cuba.discreet.com,
        Marc_Lapierre@cuba.discreet.com, dery@cuba.discreet.com,
        info-performer@sgi.com, src@sgi.com
Subject: Re: Performance problem with PF 2.2
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O


> Subject: Performance problem with PF 2.2
->
->Hello,
->
->We are in the process of upgrading our application from Performer 2.1 to 2.2;
->the upgrade was very straight forward code wise but we are having a problem
->with performance. The lost in performance occurs in the Performer APP stage
->process. In PF 2.1, the application APP thread runs at 7-8 msec while in PF
->2.2, it runs at 12-14 msec.
->
->Performance tests on those two versions were made on the same machine
->(ONYX2/4CPU/IR-2RM7/IRIX6.4).
->
->I thus made test comparison between the application versions and have noticed
->bizarre calls that are made in the PF 2.2 version of the software. Complete
->analysis results are available in the attachment. Analysis was made with
->speedshop, par and dbx. It shows that the 2.2 version is updating the Performer
->output window position through the X server. This is somehow annoying.
->
->The following calls are made in 2.2:
->
->pfPipeWindow::pf_updateWindow
->pfPipeWindow::pf_updateWindowOriginSize <= this is where it gets bizarre
->pfWindow::pr_updateScreenOrigin
->XTranslateCoordinates
->_XReply
-> _XRead
->_X11TransRead
->_X11TransShmBufRead
->_read
->
->The call to pfPipeWindow::pf_updateWindow() is made from pfSync(). In PF 2.1,
->no calls are made to pfWindow::pr_updateScreenOrigin() which happens in PF 2.2.

FYI, I can't catch perfly doing this beyond the initialization stage
or when I resize the window - can you?  Or is this just in your app?

It sounds to me like someone is sending the perfly window size change
events, even if the window is not really changing size.
The above stuff is a response to us detecting the X event of a ConfigureNotify,
or GravityNotify event.  Possibly you can use xscope to see if you are
seeing any other X events going around in the system.

->And also:
->
->pfPipeWindow::pf_updateWindow
->pfPipeWindow::pf_updateWindowOriginSize <= and again here
->XGetGeometry
->_XReply
->_XRead
->_XWaitForReadable
->_select
->
->The comparison tests were made on the SAME machine which does not eliminate the
->fact that this problem could be caused by the machine configuration interaction
->with PF 2.2.
->
->Nevertheless, further testing showed that this behavior does not occur on
->ONYX2/2CPU/IR and Octane platforms.

I am confused - are you sayint that the BAD behavior does or does not
occur on these platforms?

->
->My first guess on this is: bad HW configuration or unproper Performer
->initialization (DVR,GVO,????).

Doubt it.

->Any other suggestions ?
->
->And my questions are:
->
->- What could be causing the APP thread to reposition the screen position if it
->didn't change?
->- Why is a screen/window position update made through the X server instead of
->the local X display manager?

Only because we think we have been sent a reconfigure event which can
change the window position.  The only trouble is that the screen
position of the window is not included in the event.  We used to know
worry about that and just not know the position of the window on the 
screen.  We espcaped with that for a long time but folks finally 
complained about other bugs and things we couldn't support without tracking
that at least about a change we have nominally been told about. This did
make our handling of those events slower, but any events coming through
is not a real-time situation anyway.

->- How can I get rid of this ??!

Well, you can turn off our listening to any events but this sounds like
a band-aid to a problem somewhere that needs to be fixed.

To make us deaf to events, include PFPWIN_TYPE_NOXEVENTS in your
pfPWinType specification.  Now, we'll never know about the size
of a window unless you tell us with pfPWinSize.
If a user resizes a window, you'll have to tell us about it.
Again, use this if you are in an emergancy right now but lets find
the real bug.


Thanx!
src.


-- 
-----{-----{---@   -----{----{---@   -----{----{---@   -----{----{---@
Sharon Rose Clay - Silicon Graphics, Advanced Systems Dev.
src@sgi.com  (650) 933 - 1002  FAX: (650) 965 - 2658  MS 8U-590
-----{-----{---@   -----{----{---@   -----{----{---@   -----{----{---@
+>---- On May 27,  9:52am, Jean-Luc Dery wrote:
=======================================================================
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 May 28 08:04:52 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA19364 for info-performer-dist@holodeck.engr.sgi.com; Thu, 28 May 1998 07:57:35 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id HAA19337 for <info-performer@holodeck.engr.sgi.com>; Thu, 28 May 1998 07:57:34 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA28280
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 28 May 1998 07:57:33 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from quid.csd.sgi.com ([150.166.129.99]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA18750
	for <info-performer@sgi.com>; Thu, 28 May 1998 07:57:32 -0700 (PDT)
	mail_from (robj@quid.csd.sgi.com)
Received: (from robj@localhost) by quid.csd.sgi.com (980205.SGI.8.8.8/960327.SGI.AUTOCF) id HAA29470; Thu, 28 May 1998 07:51:43 -0700 (PDT)
From: "Rob Jenkins" <robj@quid.csd.sgi.com>
Message-Id: <9805280751.ZM29447@quid.csd.sgi.com>
Date: Thu, 28 May 1998 07:51:42 -0700
In-Reply-To: Scott Herod <herod@evt.com>
        "Elusive texture memory problem" (May 27,  5:32pm)
References: <356CA294.7F5A1DBE@evt.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Scott Herod <herod@evt.com>, info-performer@sgi.com
Subject: Re: Elusive texture memory problem
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

Scott

There have been various texture manager problems in the past that can give
symptoms like this under certian conditions. What you describe sounds like a GL
level problem, not Performer, as you're seeing textures that aren't from the
program you're currently running. The texture manager for each platform is
different, the platform I've seen this kind of thing on most is Impact/OCTANE
but with recent patches almost all those went away so I would suggest that you
make sure you have the latest gfx patch for the platform with the problem:

Impact: patch 1935 ( there is a later patch 2677 but I don't think that's in a
patch set yet and doesn't seem to have texture manager fixes over 1935 ).
OCTANE: patch 2895
Onyx2 iR: patch 2922
Onyx iR: patch 2327
Onyx RE2: patch 2739

Also, for OCTANE/Impact at least I know there are extra fixes in the Irix 6.5
texture manager. If you have the latest patches for your machine and still see
a problem then please get the test case down to the smallest possible that
shows the problem ( although it's more important just to have a test case even
if it's big, reducing the size just makes life easier ) then log a support call
- are you a Beta test site for Irix 6.5 ?

Cheers
Rob

On May 27,  5:32pm, Scott Herod wrote:
> Subject: Elusive texture memory problem
> Are there any known problems with performer (or gl) paging
> textures back and forth between hardware texture memory?
> (Performer 2.0.4)  In particular, we've got a performer scene
> with multiple small textures created from raster images.  If
> we repeatedly play the scene, it runs fine for ~30 times (not
> always the same number) and then one texture replaces another.
>
>     I've seen the problem occur between separate scenes, and
> it has been reported that once a Doom texture appeared where
> it couldn't possibly be created.  (Fortunately not on my machine.)
>
>     I have a lot of ideas as to what the problem is not...
> We're not confusing our pointers to the beginnings of the
> raster images.  pfDelete is called religiously.  We are not
> opening files of raster images.
>
>     I have only seen textures replace those (supposedly) created
> later, never the other way around.  I've only seen textures
> be replaced by similar sized textures.
>
>     The pfuClearTextureMemory() routine which is part of
> pfuTextureMemory corrects the problem with some scenes if it
> is called after the scene is deleted but it does not effect
> other examples.
>
>     Any suggestions of other places to look would be greatly
> appreciated.
>
> Scott Herod
> herod@evt.com
> =======================================================================
> 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 Herod



-- 
________________________________________________________________
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 May 28 09:00:32 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id IAA19602 for info-performer-dist@holodeck.engr.sgi.com; Thu, 28 May 1998 08:47:50 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id IAA19575 for <info-performer@holodeck.engr.sgi.com>; Thu, 28 May 1998 08:47:49 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id IAA55806
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 28 May 1998 08:47:48 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from scully.mugu.navy.mil ([143.113.1.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA09880
	for <info-performer@sgi.com>; Thu, 28 May 1998 08:47:46 -0700 (PDT)
	mail_from (ofriels1@qmsmtpgw.mugu.navy.mil)
Received: by scully.mugu.navy.mil; id LAA20145; Thu, 28 May 1998 11:46:30 -0400 (EDT)
Received: from tuvok.mugu.navy.mil(143.113.247.22) by scully.mugu.navy.mil via smap (4.1)
	id xma020084; Thu, 28 May 98 08:45:00 -0700
Received: from qmsmtpgw.mugu.navy.mil (qmsendgw.mugu.navy.mil) by tuvok.mugu.navy.mil (4.1/SMI-4.1)
	id AA00365; Thu, 28 May 98 08:40:59 PDT
Message-Id: <n1315777567.15547@qmsmtpgw.mugu.navy.mil>
Date: 28 May 1998 08:12:13 -0800
From: "SCOTT OFRIEL" <ofriels1@qmsmtpgw.mugu.navy.mil>
Subject: pfMultiprocess
To: info-performer@sgi.com
X-Mailer: Mail*Link SMTP-QM 4.1.0
Status: O

Greetings All,

Our Performer apps have all worked very well on the Impact and the Octane,
both single processor.  Now that we have moved these apps to the 4 processor
Onyx RE2 they stop somewhere and only get through our Performer loop once or
twice.

I tried using pfMultiprocess(PFMP_APP_CULL_DRAW) and
pfMultiprocess(PFMP_DEFAULT) to try to setup the program for multiple
processors but the only thing that works is if I put everything on one
processor using pfMultiprocess(PFMP_APPCULLDRAW).

Is there something else I must do to utilize multiple processors?

Thanks, Scott O'Friel


=======================================================================
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 May 28 09:32:34 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA19752 for info-performer-dist@holodeck.engr.sgi.com; Thu, 28 May 1998 09:23:33 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA19724 for <info-performer@holodeck.engr.sgi.com>; Thu, 28 May 1998 09:23:32 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA45739
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 28 May 1998 09:23:30 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from quid.csd.sgi.com ([150.166.129.99]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA25142
	for <info-performer@sgi.com>; Thu, 28 May 1998 09:23:29 -0700 (PDT)
	mail_from (robj@quid.csd.sgi.com)
Received: (from robj@localhost) by quid.csd.sgi.com (980205.SGI.8.8.8/960327.SGI.AUTOCF) id JAA29547; Thu, 28 May 1998 09:17:46 -0700 (PDT)
From: "Rob Jenkins" <robj@quid.csd.sgi.com>
Message-Id: <9805280917.ZM29587@quid.csd.sgi.com>
Date: Thu, 28 May 1998 09:17:45 -0700
In-Reply-To: "SCOTT OFRIEL" <ofriels1@qmsmtpgw.mugu.navy.mil>
        "pfMultiprocess" (May 28,  8:12am)
References: <n1315777567.15547@qmsmtpgw.mugu.navy.mil>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: "SCOTT OFRIEL" <ofriels1@qmsmtpgw.mugu.navy.mil>, info-performer@sgi.com
Subject: Re: pfMultiprocess
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

On May 28,  8:12am, SCOTT OFRIEL wrote:
> Subject: pfMultiprocess
> Greetings All,
>
> Our Performer apps have all worked very well on the Impact and the Octane,
> both single processor.  Now that we have moved these apps to the 4 processor
> Onyx RE2 they stop somewhere and only get through our Performer loop once or
> twice.
>
> I tried using pfMultiprocess(PFMP_APP_CULL_DRAW) and
> pfMultiprocess(PFMP_DEFAULT) to try to setup the program for multiple
> processors but the only thing that works is if I put everything on one
> processor using pfMultiprocess(PFMP_APPCULLDRAW).
>
> Is there something else I must do to utilize multiple processors?
>
> Thanks, Scott O'Friel
>
>
> =======================================================================
> 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 OFRIEL

Scott

By stop, do you mean core dump or just freeze ? Can you run with cvd/dbx can
you see what the stack trace looks like ? What you describe sounds like
something being done that depends on APPCULLDRAW being in the same process, for
example some GL calls that aren't in a draw callback and so would get called
from the DRAW process running MP. To look for that you could run with setenv
PFNFYLEVEL 7, note which processes run with which pid ( pf 2.2 should tell you
the pid of the app, cull and draw ). If you were to run ogldebug <your app>
then when ogldebug comes up it should tell you the pid making GL calls, you
might spot > pid doing this which would be bad.

One other thing to look at would be which GL you use, OCTANE/Impact are native
OpenGL machines, RE2 is native IrisGl ( although runs OGL pretty well ), do you
get the same results on the RE2 for the app compiled against OGL and IGL ?

I should add this to my email .sig but "check you have the latest patches" in
this case you should check the gfx patches and also the kernel rollup on the
RE2, see www.sgi.com/support for patchset info. If this is no help then keep
commenting stuff out until it's clear what stops the app running MP and post
details.

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  Thu May 28 11:23:15 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA20154 for info-performer-dist@holodeck.engr.sgi.com; Thu, 28 May 1998 11:20:23 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA20127 for <info-performer@holodeck.engr.sgi.com>; Thu, 28 May 1998 11:20:17 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA17107
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 28 May 1998 11:20:17 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA17656
	for <info-performer@sgi.com>; Thu, 28 May 1998 11:20:15 -0700 (PDT)
	mail_from (sbaker@link.com)
Received: from borgus.bgm.link.com (borgus.bgm.link.com [130.210.236.13])
          by lfkw10.bgm.link.com (8.8.6/RSC-RTI-1.0) with SMTP
	  id NAA19703; Thu, 28 May 1998 13:20:10 -0500 (CDT)
Date: Thu, 28 May 1998 13:19:13 -0500 (CDT)
From: Steve Baker <sbaker@link.com>
X-Sender: steve@borgus.bgm.link.com
Reply-To: Steve Baker <sbaker@link.com>
To: SCOTT OFRIEL <ofriels1@qmsmtpgw.mugu.navy.mil>
cc: info-performer@sgi.com
Subject: Re: pfMultiprocess
In-Reply-To: <n1315777567.15547@qmsmtpgw.mugu.navy.mil>
Message-ID: <Pine.SGI.3.96.980528113050.4910A-100000@borgus.bgm.link.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

On 28 May 1998, SCOTT OFRIEL wrote:

> Greetings All,
> 
> Our Performer apps have all worked very well on the Impact and the Octane,
> both single processor.  Now that we have moved these apps to the 4 processor
> Onyx RE2 they stop somewhere and only get through our Performer loop once or
> twice.
> 
> I tried using pfMultiprocess(PFMP_APP_CULL_DRAW) and
> pfMultiprocess(PFMP_DEFAULT) to try to setup the program for multiple
> processors but the only thing that works is if I put everything on one
> processor using pfMultiprocess(PFMP_APPCULLDRAW).
> 
> Is there something else I must do to utilize multiple processors?
 
No, that call is enough - you are probably suffering from the classic
problem that 99% of people converting from single CPU to multiproc
have.

Make sure that all Performer data structures are allocated out of
shared memory. This especially includes stuff you send to pfGeoSet
API: vertex arrays, normal arrays, index arrays, colour tables, etc.

Search you code for calls to malloc/calloc/new/delete/amalloc etc, and
convince yourself whether these should in fact be pfMalloc/pfCalloc.
Also, beware of global variables that are written to after the other
processes are split off.

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 May 28 18:32:58 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id SAA21374 for info-performer-dist@holodeck.engr.sgi.com; Thu, 28 May 1998 18:24:38 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id SAA21347 for <info-performer@holodeck.engr.sgi.com>; Thu, 28 May 1998 18:24:36 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id SAA92982
	for <info-performer@cthulhu.engr.sgi.com>;
	Thu, 28 May 1998 18:24:36 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id SAA25676
	for <info-performer@sgi.com>; Thu, 28 May 1998 18:24:33 -0700 (PDT)
	mail_from (mayer@poster.cae.ca)
Received: 	id UAA23418; Thu, 28 May 1998 20:09:04 -0400
Received: by gateway id AA36697; Thu, 28 May 1998 20:05:37 -0400
Received: by gateway id UAA24100; Thu, 28 May 1998 20:12:27 -0400
Sender: mayer@poster.cae.ca
Message-Id: <356DFD6A.41C6@cae.ca>
Date: Thu, 28 May 1998 20:12:26 -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: Video Format Compiler on iR
Content-Type: text/plain; charset=us-ascii; name="vfc.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="vfc.txt"
Status: O

hi,

I want to output a video signal matching the RS343 spec
out of an Infinite Reality. The Reality Engine used to offer the
following vof which matches RS343 exactly:

VOF 960x802_30i.u:
  Active Line Length:                   960 pixels, 30.99 usec.
  Vertical Active Height:               802 lines
  Nominal Line Period (total width):    1180 pixels, 38.10 usec.
  Lines Per Frame:                      875 lines
  Pixel Clock:                           30.975000 MHz, period = 32.284100 nsec.
  Horizontal Line Frequency:             26.250 KHz
  Horizontal Sync Duration:             85 pixels, 2.74 usec.
  Horizontal Back Porch Duration:       105 pixels, 3.39 usec.
  Horizontal Front Porch Duration:      30 pixels, 0.97 usec.
  Vertical Front Porch Duration:        3540 pixels, 3.0 lines, 0.11 msec
  Vertical Sync Duration:               3540 pixels, 3.0 lines, 0.11 msec
    Sync Pulse Duration:                530 pixels, 17.11 usec
    Sync Pulse Count:                   6
  Vertical Back Porch Duration:         36580 pixels, 31.0 lines, 1.18 msec
  VWALK to ACTIVID duration:            10640 pixels, 9.016949 lines
  Frame Frequency:                      30 Hz Interlaced, 2 Fields
  Flags:                                (None)

I have tried to used the VFC (Video Format Compiler) to create something
very similar to this but I'm getting some errors when compiling the format.

I know this is probably some misunderstanding about the FIELD definition
but I can't find what is wrong.  AFAIK, the number of lines defined in
the field definition is equal to the TotalLinesPerFrame but I'm still
getting an error telling me that I'm defining too much lines.

I've included my vfs file as well as the errors generated by the compiler.

If someone can help,  I would appreciate.

thanks

following is the what I called rs343.vfs

General
{
    FieldsPerFrame = 2;
    FramesPerSecond = 30.0;
    TotalLinesPerFrame = 875;
    TotalPixelsPerLine = 1180;
    ActiveLinesPerFrame = 802;
    ActivePixelsPerLine = 960;
    
    FormatName = "RS343";
}

Active Line
{
    HorizontalFrontPorch = 0.97 usec; 
    HorizontalBackPorch = 3.39 usec;
    HorizontalSync = 2.74 usec;
}

Field
{
    offset = 0;

    Vertical Sync = 
    {
        repeat 3
        {
            Length = 1.0H; 
            Low = 0 usec; 
            High = 0.11 msec;
        }
    }
    
    Vertical Back Porch =
    {
        repeat 31
        {
            Length = 1.0H; 
            Low = 0 usec; 
            High = 1.18 msec;
        }
    }

    Active =
    {
        repeat 401
        {
            Length = 1.0H; 
            Low = 0 usec; 
            High = HorizontalSync;
        }
    }

    Vertical Front Porch =
    {
        repeat 3
        {
            Length = 1.0H;
            Low = 0 usec;
            High = 0.11 msec;
        }
    }
}

Field
{
    offset = 1;

    Vertical Sync =
    {
        repeat 3
        {
            Length = 1.0H;
            Low = 0 usec;
            High = 0.11 msec;
        }
    }

    Vertical Back Porch =
    {
        repeat 31
        {
            Length = 1.0H;
            Low = 0 usec;
            High = 1.18 msec;
        }
    }

    Active =
    {
        repeat 401
        {
            Length = 1.0H;
            Low = 0 usec;
            High = HorizontalSync;
        }
    }

    Vertical Front Porch =
    {
        repeat 3
        {
            Length = 1.0H;
            Low = 0 usec;
            High = 0.11 msec;
        }
    }
}


And following is the errors I got from the compilation

[sgioms] ~/vfc> /usr/sbin/vfc -a ascii=rs343MAYER2.txt -c chip=voc1.def,board=dg4.def -o rs343.vfo /usr/people/mayer/vfc/rs343.vfs
"/usr/people/mayer/vfc/rs343.vfs", line 105: You specified sync on line 876.888 but the format has only 875 lines per frame.
Shorten your format definition.
"/usr/people/mayer/vfc/rs343.vfs", line 105: You specified sync on line 877.888 but the format has only 875 lines per frame.
Shorten your format definition.
"/usr/people/mayer/vfc/rs343.vfs", line 104: You specified sync on line 876 but the format has only 875 lines per frame.
Shorten your format definition.
"/usr/people/mayer/vfc/rs343.vfs", line 105: You specified sync on line 878.888 but the format has only 875 lines per frame.
Shorten your format definition.
Compilation completed with errors.  No video format created.
[sgioms] ~/vfc>

AGAIN, thanks a lot

-- 

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  Fri May 29 01:43:03 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id BAA22059 for info-performer-dist@holodeck.engr.sgi.com; Fri, 29 May 1998 01:34:40 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id BAA22032 for <info-performer@holodeck.engr.sgi.com>; Fri, 29 May 1998 01:34:39 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id BAA94562
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 29 May 1998 01:34:38 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from Cs.Nott.AC.UK (pat.cs.nott.ac.uk [128.243.21.19]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id BAA02493
	for <info-performer@sgi.com>; Fri, 29 May 1998 01:34:36 -0700 (PDT)
	mail_from (simon.hart@nottingham.ac.uk)
Received: from marian.cs.nott.ac.uk by pat.Cs.Nott.AC.UK id aa04724;
          29 May 98 9:34 BST
Received: from amethyst by marian.Cs.Nott.AC.UK id aa27441; 29 May 98 9:33 BST
Sender: smh@Cs.Nott.AC.UK
Message-ID: <356E724A.7548DAF1@nottingham.ac.uk>
Date: Fri, 29 May 1998 09:31:06 +0100
From: Simon M Hart <simon.hart@nottingham.ac.uk>
Organization: CIMI
X-Mailer: Mozilla 4.05 [en] (X11; I; IRIX 6.2 IP22)
MIME-Version: 1.0
To: "info-performer@sgi.com" <info-performer@sgi.com>
Subject: graded alpha channel
Content-Type: multipart/alternative; boundary="------------67C2E24FB12CB3DF91C88589"
Status: O


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

Performers

A simple problem in some ways:

[imagefile].rgb + [greyscaleimagefile].rgb = [composite imagefile].rgba

That is to say I want to use a greyscale image as the graded alpha
channel for an rgba image, for instance for putting a graded tint on a
car window.

Does any one know of an application that is readily available to combine
two such images to create an rgba file with graded alpha channel?

Thanks

Simon.

--
Simon Hart, BA DipArch.
Development Manager
CIMI
Unit 8 William Lee Buildings
Highfields Science Park
University Boulevard
Nottingham NG7 2RQ.

e-mail: simon.hart@nottingham.ac.uk

Tel: 0115 956 8997/0   Fax: 0115 956 8991

  Internet: http://www.cimi.nott.ac.uk/



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

<HTML>
Performers

<P>A simple problem in some ways:

<P>[imagefile].rgb + [greyscaleimagefile].rgb = [composite imagefile].rgba

<P>That is to say I want to use a greyscale image as the graded alpha channel
for an rgba image, for instance for putting a graded tint on a car window.

<P>Does any one know of an application that is readily available to combine
two such images to create an rgba file with graded alpha channel?

<P>Thanks

<P>Simon.
<PRE>--&nbsp;
Simon Hart, BA DipArch.&nbsp;
Development Manager&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
CIMI
Unit 8 William Lee Buildings
Highfields Science Park
University Boulevard
Nottingham NG7 2RQ.

e-mail: simon.hart@nottingham.ac.uk

Tel: 0115 956 8997/0&nbsp;&nbsp; Fax: 0115 956 8991

&nbsp; Internet: <A HREF="http://www.cimi.nott.ac.uk/">http://www.cimi.nott.ac.uk/</A></PRE>
&nbsp;</HTML>

--------------67C2E24FB12CB3DF91C88589--

=======================================================================
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 May 29 02:30:59 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id CAA22309 for info-performer-dist@holodeck.engr.sgi.com; Fri, 29 May 1998 02:24:31 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id CAA22282 for <info-performer@holodeck.engr.sgi.com>; Fri, 29 May 1998 02:24:30 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id CAA20999
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 29 May 1998 02:24:30 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from strato.geo.unizh.ch (strato.geo.unizh.ch [130.60.176.64]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id CAA12764
	for <info-performer@sgi.com>; Fri, 29 May 1998 02:24:27 -0700 (PDT)
	mail_from (hilko@geo.unizh.ch)
Received: from aquilla.geo.unizh.ch ([130.60.176.5]) by strato.geo.unizh.ch
          (Post.Office MTA v3.1.2 release (PO203-101c)
          ID# 0-42730U500L100S0) with SMTP id AAA8519;
          Fri, 29 May 1998 11:24:24 +0200
Received: from geo.unizh.ch by aquilla.geo.unizh.ch (950413.SGI.8.6.12) id LAA26781; Fri, 29 May 1998 11:24:21 +0200
Sender: hilko@geo.unizh.ch (Hilko Hoffmann)
Message-ID: <356E7EC5.34C24C1F@geo.unizh.ch>
Date: Fri, 29 May 1998 11:24:21 +0200
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: Simon M Hart <simon.hart@nottingham.ac.uk>, info-performer@sgi.com
Subject: Re: graded alpha channel
References: <356E724A.7548DAF1@nottingham.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Simon M Hart wrote:

>  Performers
>
> A simple problem in some ways:
>
> [imagefile].rgb + [greyscaleimagefile].rgb =
> [composite imagefile].rgba
>
> That is to say I want to use a greyscale image
> as the graded alpha channel for an rgba image,
> for instance for putting a graded tint on a car
> window.
>
> Does any one know of an application that is
> readily available to combine two such images to
> create an rgba file with graded alpha channel?
>
> Thanks
>
> Simon.
>
> --
> Simon Hart, BA DipArch.
> Development Manager
> CIMI
> Unit 8 William Lee Buildings
> Highfields Science Park
> University Boulevard
> Nottingham NG7 2RQ.
>
> e-mail: simon.hart@nottingham.ac.uk
>
> Tel: 0115 956 8997/0   Fax: 0115 956 8991
>
>   Internet: http://www.cimi.nott.ac.uk/
>
>

ADOBE Photoshop  for SGI is able to do such image
processing - we use it to create alpha channels.
Note: Photoshop for other platforms than SGI
doesn't know the SGI rgba image format!


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  Fri May 29 07:22:55 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA22820 for info-performer-dist@holodeck.engr.sgi.com; Fri, 29 May 1998 07:16:46 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id HAA22793 for <info-performer@holodeck.engr.sgi.com>; Fri, 29 May 1998 07:16:45 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA57884
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 29 May 1998 07:16:44 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from mh2.cts.com (mh2.cts.com [205.163.24.68]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA17466
	for <info-performer@sgi.com>; Fri, 29 May 1998 07:10:02 -0700 (PDT)
	mail_from (danstipe@cts.com)
Received: from [204.212.158.123] (danstipe.cts.com [204.212.158.123]) by mh2.cts.com (8.8.7/8.8.5) with ESMTP id HAA23198; Fri, 29 May 1998 07:09:52 -0700 (PDT)
X-Sender: danstipe@sd.cts.com
Message-Id: <v03007800b1947f204805@[204.212.158.123]>
In-Reply-To: <356E7EC5.34C24C1F@geo.unizh.ch>
References: <356E724A.7548DAF1@nottingham.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 29 May 1998 07:10:39 -0800
To: Hilko Hoffmann <hilko@geo.unizh.ch>
From: Daniel Stipe <danstipe@cts.com>
Subject: Re: graded alpha channel
Cc: info-performer@sgi.com
Status: O

>Simon M Hart wrote:
>
>>  Performers
>>
>> A simple problem in some ways:
>>
>> [imagefile].rgb + [greyscaleimagefile].rgb =
>> [composite imagefile].rgba
>>
>> That is to say I want to use a greyscale image
>> as the graded alpha channel for an rgba image,
>> for instance for putting a graded tint on a car
>> window.
>>
>> Does any one know of an application that is
>> readily available to combine two such images to
>> create an rgba file with graded alpha channel?
>>
>> Thanks
>>
>> Simon.
>>
>> --
>> Simon Hart, BA DipArch.
>> Development Manager
>> CIMI
>> Unit 8 William Lee Buildings
>> Highfields Science Park
>> University Boulevard
>> Nottingham NG7 2RQ.
>>
>> e-mail: simon.hart@nottingham.ac.uk
>>
>> Tel: 0115 956 8997/0   Fax: 0115 956 8991
>>
>>   Internet: http://www.cimi.nott.ac.uk/
>>
>>
>
>ADOBE Photoshop  for SGI is able to do such image
>processing - we use it to create alpha channels.
>Note: Photoshop for other platforms than SGI
>doesn't know the SGI rgba image format!
>

There is a plug-in which we use on the Mac to read SGI rgb.  I'm not sure
it handles the RGBA format, but I'll try to check.

>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/
>****************************************************************


Regards,

Dan

----------------------------------------------------------
Dan Stipe               (619) 578-8914 ph/fax
President               e:mail danstipe@cts.com
VERTx Inc.              PO Box 910135, San Diego, CA 92191
----------------------------------------------------------


=======================================================================
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 May 29 08:12:20 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id IAA23033 for info-performer-dist@holodeck.engr.sgi.com; Fri, 29 May 1998 08:02: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 IAA23006 for <info-performer@holodeck.engr.sgi.com>; Fri, 29 May 1998 08:02:21 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id IAA92121
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 29 May 1998 08:02:20 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from quid.csd.sgi.com ([150.166.129.99]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA06529
	for <info-performer@sgi.com>; Fri, 29 May 1998 08:02:19 -0700 (PDT)
	mail_from (robj@quid.csd.sgi.com)
Received: (from robj@localhost) by quid.csd.sgi.com (980205.SGI.8.8.8/960327.SGI.AUTOCF) id HAA32048; Fri, 29 May 1998 07:56:30 -0700 (PDT)
From: "Rob Jenkins" <robj@quid.csd.sgi.com>
Message-Id: <9805290756.ZM32451@quid.csd.sgi.com>
Date: Fri, 29 May 1998 07:56:29 -0700
In-Reply-To: Simon M Hart <simon.hart@nottingham.ac.uk>
        "graded alpha channel" (May 29,  9:31am)
References: <356E724A.7548DAF1@nottingham.ac.uk>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Simon M Hart <simon.hart@nottingham.ac.uk>,
        "info-performer@sgi.com
 " <info-performer@sgi.engr.sgi.com>
Subject: Re: graded alpha channel
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

> A simple problem in some ways:
>
> [imagefile].rgb + [greyscaleimagefile].rgb = [composite imagefile].rgba
>
> That is to say I want to use a greyscale image as the graded alpha
> channel for an rgba image, for instance for putting a graded tint on a
> car window.
>
> Does any one know of an application that is readily available to combine
> two such images to create an rgba file with graded alpha channel?
>
> Thanks
>
> Simon.

If you have eoe.sw.imagetools installed then you can use oneband to break any
channel out of and image and cglue to stick any channels together to form an
image. For what you want to do perhaps you could make the greyscale image in
showcase or something ( the 'greyscale' imagetool will make a greyscale also )
in showcase you could make the greyscale go from one corner to another say
though. Once you have the alpha just use cglue with you existing rgb image.

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 May 29 09:15:07 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA23279 for info-performer-dist@holodeck.engr.sgi.com; Fri, 29 May 1998 09:07: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 JAA23252 for <info-performer@holodeck.engr.sgi.com>; Fri, 29 May 1998 09:07:31 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA77951;
	Fri, 29 May 1998 09:07:30 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id JAA03365; Fri, 29 May 1998 09:07:28 -0700 (PDT)
	mail_from (dery@discreet.com)
Received: from cuba by helios.Discreet.QC.CA
	id MAA09841; Fri, 29 May 1998 12:07:01 -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 MAA20909; Fri, 29 May 1998 12:07:10 -0400
Received: (from dery@localhost) by atlantis (950413.SGI.8.6.12/) id MAA13227; Fri, 29 May 1998 12:07:09 -0400
From: "Jean-Luc Dery" <dery@discreet.com>
Message-Id: <9805291207.ZM13237@atlantis>
Date: Fri, 29 May 1998 12:07:09 -0400
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: info-performer@sgi.com, src@rose.engr.sgi.com
Subject: More on performance problem with PF 2.2
Cc: amit@cuba.discreet.com, Marc_Lapierre@cuba.discreet.com,
        dery@cuba.discreet.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: O

Hi again,

I've been trying to figure the Performance problem in the APP process in
Performer 2.2. This mail refers to the one I sent earlier this week. Here's
what I have so far:

1 - I'm pretty sure that the application is sending window size change events
even if the window is not really changing size. And I think that this is
happening within Performer.

2- Indeed, setting the pfPipeWindow PFPWIN_TYPE_NOXEVENTS solves the problem,
but this is not an acceptable solution, well not for us.

3- Perfly is suffering from this disease two (FIIIOUUUU).


Conditions for reproducing the problem:

- ONYX2/4CPU (so that we can lock down processes)
- phase set to PFPHASE_LOCK
- multi processing set to PFMP_APP_CULL_DRAW
- lock all processes on CPU's (just locking the DRAW process does not make the
system behave badly)
- resize the pfPipeWindow

Here's how to see what's going on:

1- Start perfly -> perfly -L -m6 -n4 -W720,486 shinycow.obj (I like that one)
2- Attach "par" command to APP process -> par -s -SS -P<whatever>
3- Or attach "par" command to APP process  and use grep to only see X call; it
makes it easier to monitor -> par -s -SS -P<whatever> | grep read
4- Using the mouse, move (not resize) the PF output window. You will see a few
read commands go through in the par session which is perfectly normal, we're
moving the window through the X server. Repeat as many times as you want, its
behaving properly.
5- NOW, using the mouse again, resize the PF output window. You will see read
commands go through in the par session and they never stop. The resize state
procedure becomes sticky and the APP stage is requested to resize the PF window
at every frame.
6- If you want to continue, you can stall the draw process with dbx. You will
then notice that although the APP is waiting, it never receives X resizing
calls. In this last experience, just use par -s -SS -P<whatever>.

Conclusions:

When the APP stage process is locked on a CPU, internal handling of the
pfPipeWindow for managing the window starts behaving badly. The sticky resizing
problem is most certainly something that as to do with the DRAW process.

What I need:

Is there a way, to get rid of this cleanly. We do need to lock down process in
order to manage and balance our system. If this is a problem in Performer 2.2,
could we temporarily hack it until its fixed. Something like accessing specific
memory location through pointers to reset some internal flag ???

We need to upgrade to PF2.2 and would appreciate if this issue could be
resolved soon.

Thanks for your support on this and for any suggestions.

Jean-Luc



-- 
_____________________________________________________________________________

Jean-Luc Dery                         Discreet Logic
Technical Leader                      10 Duke Street
3-D Graphics Technology and           Montreal (Quebec), Canada, H3C 2L7
Realtime Systems                      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  Fri May 29 10:12:06 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA23544 for info-performer-dist@holodeck.engr.sgi.com; Fri, 29 May 1998 10:02: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 KAA23517 for <info-performer@holodeck.engr.sgi.com>; Fri, 29 May 1998 10:02:28 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA41148
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 29 May 1998 10:02:27 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from Cs.Nott.AC.UK (pat.cs.nott.ac.uk [128.243.21.19]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id KAA26965
	for <info-performer@sgi.com>; Fri, 29 May 1998 10:02:25 -0700 (PDT)
	mail_from (simon.hart@nottingham.ac.uk)
Received: from marian.cs.nott.ac.uk by pat.Cs.Nott.AC.UK id aa28445;
          29 May 98 18:00 BST
Received: from amethyst by marian.Cs.Nott.AC.UK id aa26019; 29 May 98 18:00 BST
Sender: smh@Cs.Nott.AC.UK
Message-ID: <356EE904.357F5B0D@nottingham.ac.uk>
Date: Fri, 29 May 1998 17:57:41 +0100
From: Simon M Hart <simon.hart@nottingham.ac.uk>
Organization: CIMI
X-Mailer: Mozilla 4.05 [en] (X11; I; IRIX 6.2 IP22)
MIME-Version: 1.0
To: "info-performer@sgi.com" <info-performer@sgi.com>
Subject: graded alpha channel 2
Content-Type: multipart/alternative; boundary="------------6085CA29FB1EC0C1893F505F"
Status: O


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

Performers

Thanks for the help so far- still no joy. Using Gimp I get this, which
is not quite what I want. The alpha channel is not graded- it has
imposed some sort of yes/no threshold.

See attached file.

Any ideas?


Simon.

--
Simon Hart, BA DipArch.
Development Manager
CIMI
Unit 8 William Lee Buildings
Highfields Science Park
University Boulevard
Nottingham NG7 2RQ.

e-mail: simon.hart@nottingham.ac.uk

Tel: 0115 956 8997/0   Fax: 0115 956 8991

  Internet: http://www.cimi.nott.ac.uk/



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

<HTML>
Performers

<P>Thanks for the help so far- still no joy. Using Gimp I get this, which
is not quite what I want. The alpha channel is not graded- it has imposed
some sort of yes/no threshold.

<P>See attached file.

<P>Any ideas?
<BR>&nbsp;

<P>Simon.
<PRE>--&nbsp;
Simon Hart, BA DipArch.&nbsp;
Development Manager&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
CIMI
Unit 8 William Lee Buildings
Highfields Science Park
University Boulevard
Nottingham NG7 2RQ.

e-mail: simon.hart@nottingham.ac.uk

Tel: 0115 956 8997/0&nbsp;&nbsp; Fax: 0115 956 8991

&nbsp; Internet: <A HREF="http://www.cimi.nott.ac.uk/">http://www.cimi.nott.ac.uk/</A></PRE>
&nbsp;</HTML>

--------------6085CA29FB1EC0C1893F505F--

=======================================================================
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 May 29 12:09:47 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA23877 for info-performer-dist@holodeck.engr.sgi.com; Fri, 29 May 1998 11:58: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 LAA23850 for <info-performer@holodeck.engr.sgi.com>; Fri, 29 May 1998 11:58:25 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA74303
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 29 May 1998 11:58:23 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA20425
	for <info-performer@sgi.com>; Fri, 29 May 1998 11:58:23 -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 (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA04075;
	Fri, 29 May 1998 11:58:22 -0700 (PDT)
	mail_from (dorbie@sgi.com)
Received: from sgi.com (localhost [127.0.0.1]) by multipass.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA06505; Fri, 29 May 1998 11:58:17 -0700 (PDT)
Sender: dorbie@sgi.com
Message-ID: <356F0549.A0B9F291@sgi.com>
Date: Fri, 29 May 1998 11:58:17 -0700
From: Angus Dorbie <dorbie@sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5 IP22)
MIME-Version: 1.0
To: Simon M Hart <simon.hart@nottingham.ac.uk>
CC: "info-performer@sgi.com" <info-performer@sgi.com>
Subject: Re: graded alpha channel
References: <356E724A.7548DAF1@nottingham.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Simon M Hart wrote:
> 
> Performers
> 
> A simple problem in some ways:
> 
> [imagefile].rgb + [greyscaleimagefile].rgb = [composite
> imagefile].rgba
> 
> That is to say I want to use a greyscale image as the graded alpha
> channel for an rgba image, for instance for putting a graded tint on a
> car window.
> 
> Does any one know of an application that is readily available to
> combine two such images to create an rgba file with graded alpha
> channel?
> 

Paul Haeberlis tools probably let you do this. There on the Developers
Toolbox but they may also ship with some component of the OS.

I tend to use MultiGen for this type of thing.
In the image editor you can add an alpha channel convert intensity to
alpha, grab the alpha image as a brush load the rgb image add an alpha
channel and paint the alpha information from the brush taken from the
other image.

Or something like that.

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 May 29 16:01:11 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA24370 for info-performer-dist@holodeck.engr.sgi.com; Fri, 29 May 1998 15:45:44 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id PAA24343 for <info-performer@holodeck.engr.sgi.com>; Fri, 29 May 1998 15:45:43 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id PAA58521
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 29 May 1998 15:45:42 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
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: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA16014
	for <info-performer@sgi.com>; Fri, 29 May 1998 15:45:35 -0700 (PDT)
	mail_from (prakash@drawcomp.com)
Received: (from nobody@localhost)
	by amber.drawcomp.com (8.8.5/8.8.5) id SAA29600;
	Fri, 29 May 1998 18:44:19 -0400 (EDT)
X-Authentication-Warning: amber.drawcomp.com: nobody set sender to <prakash@drawcomp.com> using -f
Received: from amber.drawcomp.com(10.0.0.2) by amber.drawcomp.com via smap (V2.0)
	id xma029598; Fri, 29 May 98 18:44:06 -0400
Sender: gpmahesh@drawcomp.com
Message-ID: <356F3A36.9D55A6E0@drawcomp.com>
Date: Fri, 29 May 1998 18:44:06 -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.3 IP32)
MIME-Version: 1.0
To: Performer Mailing List <info-performer@sgi.com>
CC: Remi Arnaud <remi@samurai.engr.sgi.com>
Subject: Getting the scene location
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

Hello,

I need to know the 'location' of the viewer in the scene space. Getting
the base viewpoint matrix is simple, but having problems with getting
the matrix that's been modified as a result of any mouse movement. At
the moment I have the following code which works fine except for one
problem. In perfly the sceneDCS used for the trackball mode is deleted
when you switch to drive or fly, so it defaults when you switch back to
trackball mode from drive or fly mode. The xformer & viewMat matrixes
are not updated while in trackball mode, so that will not work either.
Is there any simple solution to obtaining the xyz 'location' of the
viewer within the scene? 

pfMatrix * 
gfx_perf::getMouseMatrix() 
{ 
  static pfMatrix matr, offs; 
  if(ViewState->xformerModel != PFITDF_TRACKBALL) { 
    //matr = ViewState->viewMat; 
    ViewState->xformer->getMat(matr); 
    matr.mat[3][0] = -matr.mat[3][0]; 
    matr.mat[3][1] = -matr.mat[3][1]; 
    matr.mat[3][2] = -matr.mat[3][2]; 
  } else { 
    ViewState->sceneDCS->getMat(matr); 
    matr.mat[3][1] += ViewState->sceneSize; 
  } 
} 

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  Fri May 29 19:08:22 1998
Received: (from guest@localhost) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id SAA24797 for info-performer-dist@holodeck.engr.sgi.com; Fri, 29 May 1998 18:53:05 -0700
Return-Path: <guest>
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by holodeck.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id SAA24770 for <info-performer@holodeck.engr.sgi.com>; Fri, 29 May 1998 18:53:04 -0700
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id SAA57295
	for <info-performer@cthulhu.engr.sgi.com>;
	Fri, 29 May 1998 18:53:03 -0700 (PDT)
	mail_from (owner-info-performer@sgi.sgi.com)
Received: from imo21.mx.aol.com (imo21.mx.aol.com [198.81.17.65]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA10204
	for <info-performer@sgi.com>; Fri, 29 May 1998 18:53:01 -0700 (PDT)
	mail_from (PASociety@aol.com)
From: PASociety@aol.com
Received: from PASociety@aol.com
	by imo21.mx.aol.com (IMOv14_b1.1) id 8IVJa12330
	for <info-performer@sgi.com>; Fri, 29 May 1998 21:52:26 +2000 (EDT)
Message-ID: <a19ca9ae.356f665b@aol.com>
Date: Fri, 29 May 1998 21:52:26 EDT
To: info-performer@sgi.com
Mime-Version: 1.0
Subject: V-HUMANS: VH3: June 16/17, Universal City Hilton
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
X-Mailer: AOL 3.0 for Windows 95 sub 18
Status: O

****   IMPORTANT CONFERENCE ANNOUNCEMENT !!! ****

The Performance Animation Society would like to inform you that the annual
"Virtual Humans 3" Conference is fast approaching on June 16-17 th in
Universal City, CA. at the Hilton. This year promises many innovations and
excitement!

For a complete show synopsis please visit their website at:

Virtual Humans 3

http://www.vrnews.com/eventsvh3main.html

Greg Panos, Founding Co-Director of the "Performance Animation Society" will
be making a 1/2 hour evening dinner presentation; "A potpourri of human
simulation examples form the entertainment industry in Los Angeles".

There are many other exciting events palnned for the conference. Please be
sure to register as soon as possible as space is limited.

This message has been a courtesy of  "The Performance Animation Society"

                       PLEASE PAS THE WORD !!

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