Партнёры:
Хостинг:
Archive-name: sgi/faq/performer
Last-modified: Wed Oct 20 1:00:04 CDT 1999
Posting-Frequency: Twice monthly
URL: http://www-viz.tamu.edu/~sgi-faq/
SGI performer Frequently Asked Questions (FAQ)
This is one of the Silicon Graphics FAQ series, which consists of:
SGI admin FAQ - IRIX system administration
SGI apps FAQ - Applications and miscellaneous programming
SGI audio FAQ - Audio applications and programming
SGI diffs FAQ - Changes to the other FAQs since the last posting
SGI graphics FAQ - Graphics and user environment customization
SGI hardware FAQ - Hardware
SGI impressario FAQ - IRIS Impressario
SGI inventor FAQ - IRIS Inventor
SGI misc FAQ - Introduction & miscellaneous information
SGI movie FAQ - Movies
SGI performer FAQ - IRIS Performer
SGI pointer FAQ - Pointer to the other FAQs
SGI security FAQ - IRIX security
Read the misc FAQ for information about the FAQs themselves. Each FAQ is
posted to comp.sys.sgi.misc and to the news.answers and comp.answers
newsgroups (whose purpose is to store FAQs) twice per month. If you
can't find one of the FAQs with your news program, you can get it from
ftp://viz.tamu.edu/pub/sgi/faq/
ftp://rtfm.mit.edu/pub/usenet/news.answers/sgi/faq/
(rtfm.mit.edu is home to many other FAQs and informational documents,
and is a good place to look if you can't find an answer here.) The FAQs
are on the World Wide Web at
http://www-viz.tamu.edu/~sgi-faq/
If you can't use FTP or WWW, send mail to mail-server@rtfm.mit.edu with
the word 'help' on a line by itself in the text, and it will send you a
document describing how to get files from rtfm.mit.edu by mail. Send the
command 'send usenet/news.answers/sgi/faq/misc' to get the SGI misc FAQ,
and similarly for the other FAQs. Send the command 'send
usenet/news.answers/internet-services/access-via-email' to get the
"Accessing the Internet by E-Mail FAQ".
You may distribute the SGI FAQs freely and we encourage you to do so.
However, you must keep them intact, including headers and this notice,
and you must not charge for or profit from them. Contact us for other
arrangements. We can't be responsible for copies of the SGI FAQs at
sites which we do not control, and copies published on paper or CD-ROM
are certain to be out of date. The contents are accurate as far as we
know, but the usual disclaimers apply. Send additions and changes to
sgi-faq@viz.tamu.edu.
Topics covered in this FAQ:
---------------------------
-1- ================ General Topics ==================
-2- What is IRIS Performer?
-3- Where can I get more technical information about IRIS Performer?
-4- Where can I get more product information about IRIS Performer?
-5- The IRIS Performer mailing list
-6- The IRIS Performer FTP Archives
-7- The IRIS Performer WWW Pages in Silicon Surf
-8- The IRIS Performer Technical Report
-9- How does IRIS Performer relate to IRIS Inventor?
-10- What version of IRIS Performer should I use?
-11- What patches should be used with IRIS Performer?
-12- What version of IRIS Performer am I currently running?
-13- What are all of the released versions of IRIS Performer?
-14- Does IRIS Performer use IRIS GL or OpenGL?
-15- Is there a IRIS Performer file format?
-16- What database file formats can IRIS Performer read?
-17- Is there an IRIS Inventor file reader for IRIS Performer?
-18- What are the .tlf files used by the Performer Town and Village?
-19- What are the minimum requirements for using IRIS Performer?
-20- Binary Compatibility on different machines
-21- Binary Compatibility on different releases
-22- Guaranteeing Real Time performance
-23- How do I make GL calls from within a IRIS Performer program?
-24- How do I overlay graphics on top of my Performer scene?
-25- What is the difference between phases FREE, FLOAT, and LOCK?
-26- Use of PFTMPDIR to configure shared memory
-27- Which rendering primitives does IRIS Performer support?
-28- How do I do triangle meshes in Performer?
-29- ================= Known Problems =================
-30- Video Rate sometimes reported incorrectly
-31- Problems with Performer Town or Village demos
-32- Antialiasing
-33- Coplanar Polygons & pfDecal on certain platforms
-34- Networked graphics (DGL & GLX)
-35- Transparency
-36- Gangdraw and cursor loading
-37- Frame control on low- and mid-range machines
-38- Timing on pre-1992 platforms
-39- 2.0 Warnings from ld when building on IRIX 6.2
-40- 2.0 Bug OpenGL functions missing when building static executables
-41- 2.0 Bug Z buffer problems when moving windows on 5.3 EXtreme
-42- 2.0 Bug Use of more than 512 simultaneous textures
-43- 2.0 Bug IRIS GL on dual-head systems
-44- 2.0 Bug Resizing of pfPipeWindows in MP X apps
-45- 2.0 Bug Applying frustums transformed by pfOrthoXformFrust
-46- 2.0 Bug pfFlatten with pfCycleBuffer attribute arrays
-47- 2.0 Bug Sorting lights with pfChanBinSort()
-48- 2.0 Bug OpenGL disables back material modes
-49- 2.0 Bug CPU statistics in IRIX 6
-50- 2.0 Bug pfdLoadFile_flt FLT loader in IRIX 6
-51- 2.0 Bug hello sample program in IRIX 6
-52- 2.0 Bug Forked X input handing in IRIX 6.2
-53- 2.0 Bug Intersections with pfBillboard nodes
-54- 2.0 Bug Channel fade LOD attributes & mixed gfx configs
-55- 2.0 Bug libpfui C API incomplete
-56- 2.0 Bug libpfdb pfdLoadFile_dxf incomplete
-57- 2.0 Bug libpfdb pfdLoadFile_sgo incomplete
-58- 2.0 Bug IRIS GL perfly on Indy
-59- 2.0 Bug pguide/libpf/C/pipewin sample program
-60- 2.0 Bug pguide/libpf/C/lpstate sample program
-61- 2.0 Bug pfInitClock() and Video Rate on 250MHz IMPACT
-62- 1.2 Bug Billboard normals and intersections
-63- 1.2 Bug Incompatibility with IRIX 6.1 XFS
-64- 1.2 Bug Billboards with multiple pfGeoSets
-65- 1.2 Bug Flattening transformation hierarchies
-66- 1.2 libpf Bug Hang on Exit, 5.2 VGX
-67- 1.2 libpf Cull with overlapped draw latency
-68- 1.2 libpf Cull with overlapped draw hang
-69- 1.2 libpf Transparency Sorting
-70- 1.2 libpf Multiple EarthSky fog
-71- 1.2 libpf Bug Limit Phase
-72- 1.2 libpr Highlighting when using wireframe
-73- 1.2 libpf APPCULLDRAW does not honor LIMIT/FLOAT/LOCK phases
-74- 1.2 libpf Phase toggling overlapped cull and draw
-75- 1.2 libpf pfDataPool warning on exit
-76- 1.2 libpf Multi-channel stats warning messages
-77- 1.2 libpf Video warnings on Indy when multiprocessed
-78- 1.2 stats Frame statistics for lightpoints
-79- 1.2 stats Pixel fill statistics under 4.0.5 on RealityEngine
-80- 1.2 libpr Directional pfLightPoints
-81- 1.2 libpfutil pfuCollide is jerky
-82- 1.2 libpfutil pfuSaveImage broken
-83- 1.2 libpfsgi pfLoadDxf loader is incomplete
-84- 1.2 libpfsgi pfLoadIv loader is incomplete
-85- 1.2 GLX Overlay text with GLX on 4.0.5
-86- 1.2 GLX Toggling antialiasing with GLX on 4.0.5 RealityEngine
-87- 1.2 GLX Toggling antialiasing with GLX on any RealityEngine
-88- 1.2 GLX on 4.0.5 Indigo, sample programs hang on startup.
-89- 1.2 samples smallfly drive models broken
-90- 1.2 samples pickfly drops core under abuse
-91- 1.2 samples detail example broken on 4.0.5
-92- 1.2 friends Belvis makefile requires pmake
-93- 1.2 friends Toon has bad models and textures
-94- 1.2 docs pfuGetGLXWin wrong on reference page
-95- 1.2 docs pfuLockDownApp gives the incorrect location
-96- 1.1 Bug with FP underflow
-97- 1.1 Bug with Multipipe Onyx
-98- 1.1 Bug Installing on Indy or Indigo2 XL
-99- 1.1 Bug Unable to determine Indy graphics type
-100- 1.1 Bug perfly cannot find libpf.so on Indy running 5.1
-101- 1.1 Bug perfly FP error messages in 5.0.1
-102- 1.1 Bug Installation on IRIX 5.2 - missing prerequisites
-103- 1.0/1.1 Bug intersections with pfSwitch'es
-104- 1.0/1.1 Bug with pfTexture()
-105- 1.0/1.1 Bug with pfAntiAlias()
-106- 1.0/1.1 Bug with pfFlatten()
-107- 1.0/1.1 Bug with pfSequences
-108- 1.0/1.1 Bug with pfClosestPtOnPlane()
-109- 1.0/1.1 Bug on ELAN/XS with wireframe PFGS_QUADS
-110- 1.0/1.2-IRIX4 Bug Z buffer configuration on 4.0.5 RealityEngine
-111- 1.0 Bug pfInit(): mmap failed for /dev/zero
-112- 1.0 Doc Bug in pfMakePolarSeg() man page
-113- 1.0 Doc Bug in pfDispList() man page
-114- 1.0 Doc Bug in PFPG (simple.c)
-115- 1.0 Bug in pfGetTime()
-116- 1.0 Bug in pfNodeBBox()
-117- 1.0 Bug in pfInitGfx() with Z-buffer on RealityEngine
-118- 1.0 Bug in libpfflt combineLODs()
-119- 1.0 Bug with two-sided material and pfMtlColorMode()
-120- 1.0 Bug in pfFilePath()
-121- 1.0 Bug in pfGetCurGState()
-122- 1.0 Bug in pfGetCurState()
-123- 1.0 Bug with cloned scenes
-124- 1.0 Bug intersections in collide.c
-125- 1.0 Bug with flattened pfLightPoints
-126- 1.0 Bug intersections with pfSequences
-127- 1.0 Bug intersections with non-indexed quads
----------------------------------------------------------------------
Subject: -1- ================ General Topics ==================
Date: 12 Dec 95 00:00:01 EST
------------------------------
Subject: -2- What is IRIS Performer?
Date: 12 Dec 95 00:00:01 EST
IRIS Performer provides a powerful and extensible programming
interface (with ANSI C and C++ bindings) for creating real-time
visual simulation and other interactive graphics applications.
IRIS Performer 2.0 supports both the IRIS Graphics Library (IRIS
GL) and the industry standard OpenGL graphics library; these
libraries combine with the IRIX operating system and REACT
extensions to form the foundation of a powerful suite of tools and
features for creating real-time visual simulation applications on
Silicon Graphics systems.
IRIS Performer is an integral part of the Onyx/Onyx2 RealityEngine
& InfiniteReality and Indigo2/Octane Impact graphics systems and
provides interfaces to advanced features of RealityEngine-class
graphics. IRIS Performer is compatible with uniprocessor and
multiprocessor SGI graphics platforms and attains maximum
performance on all. IRIS Performer provides an extensible basis
for creating real-time 3D graphics applications in the fields of
visual simulation, entertainment, virtual reality, broadcast video,
and computer aided design. IRIS Performer is the flexible,
intuitive, toolkit-based solution for developers who want to
optimize performance on Silicon Graphics systems.
IRIS Performer consists of two main libraries, libpf and libpr, and
four associated libraries, libpfdu, libpfdb, libpfui, and
libpfutil.
The basis of IRIS Performer is the performance rendering library
libpr, a low level library providing high speed rendering functions
based on pfGeoSets, efficient graphics state control using
pfGeoStates, and other application- neutral functions.
Layered above libpr is libpf, a real-time visual simulation
environment providing a high-performance multi-processing database
rendering system that takes best advantage of IRIS symmetric
multiprocessing CPU hardware.
The database utility library libpfdu provides powerful functions
for defining both geometric and appearance attributes of three
dimensional objects, encourages sharing of state and materials and
generates efficient triangle strips from independent polygonal
input.
The database library libpfdb uses the facilities of libpfdu, libpf,
and libpr to import database files in many popular industry
standard database formats. These loaders also serve as a guide to
developers creating new database importers.
libpfui contains user interface building blocks for creating
manipulators common to many interactive applications. This library
has both a C and C++ API and is GL independent.
Completing the suite of libraries is libpfutil, the IRIS Performer
utility library. It provides a collection of important convenience
routines implementing such diverse tasks as smoke effects,
MultiChannel Option support, graphical user interface tools, X and
IRIS GL event collection and management, and traversal functions.
For aid in application development, IRIS Performer includes sample
application source code ranging from simple programs to illustrate
particular features to the comprehensive, GUI-driven file viewer
perfly.
In addition to these SGI-developed tools, IRIS Performer also
includes a very large repository of sample code, databases, games,
and movies contributed by the Friends of Performer: companies and
individuals with services of general interest to the IRIS Performer
community. We encourage you to sample their wares.
------------------------------
Subject: -3- Where can I get more technical information about IRIS
Performer?
Date: 12 Dec 95 00:00:01 EST
The three best resources for additional information are:
- The IRIS Performer mailing list
- The IRIS Performer FTP Archives
- The Performer WWW pages in Silicon Surf
- The IRIS Performer Technical Report
See below for further information.
------------------------------
Subject: -4- Where can I get more product information about IRIS
Performer?
Date: 12 Dec 95 00:00:01 EST
For product information about IRIS Performer or SGI Visual
Simulation issues contact Ralph Humphries (ralphh@asd.sgi.com). To
learn about SGI Virtual Reality solutions contact Joshua Mogal
(mogal@asd.sgi.com). To just give in and buy a copy call SGI
Direct at 1-800-800-7441 (product SC4-PERF-2.0), or to have both a
demonstration and a presentation call your local SGI sales office.
Brochure-style information about IRIS Performer is also available
from the Performer WWW pages in Silicon Surf (see below)
------------------------------
Subject: -5- The IRIS Performer mailing list
Date: 12 Dec 95 00:00:01 EST
The IRIS Performer mailing list is a resource for developers who
are using IRIS Performer to maximize the performance of their
graphics applications on Silicon Graphics hardware. The list is an
unmoderated, free-form discussion of IRIS Performer with issues
both technical and non-technical; and provides feedback to Silicon
Graphics about the product. Much like the comp.sys.sgi.*
newsgroups, it is not an official support channel but is monitored
by the IRIS Performer development team, so it's an excellent source
of early information about upcoming events and product features, as
well as a venue for asking questions and having them answered.
To become a subscriber to the IRIS Performer mailing list you must
send email to:
info-performer-request@sgi.com
New subscribers are added "by hand". Once your request is processed
you will recieve submission/posting instructions, some guidelines,
and a current copy of the Performer Frequently-Asked-Questions (FAQ)
list.
The mailing list has become rather large and carries several
hundred messages per month. A performer newsgroup with a gateway
to the mailing list may be created if there is enough interest.
Mailing list archives are available in the Performer FTP area (see
below) in ftp://sgigate.sgi.com/pub/Performer/monthly-archives/
------------------------------
Subject: -6- The IRIS Performer FTP Archives
Date: 12 Dec 95 00:00:01 EST
An archive of Performer-related material is available via anonymous
FTP: ftp://sgigate.sgi.com/pub/Performer
Current Contents:
README - Overview file
FAQ - The Performer FAQ
INFO-PERFORMER - information about the Performer mailing list
src/ - Sample source code & misc patches
docs/ - IRIS Performer docs including SIGGRAPH '94 paper
selected-topics/ - directory of info, Q&A, etc from mailing list
monthly-archives/ - raw archives (monthly) of the mailing list
CortaillodCentre/ - goodies from SGI's Cortaillod Office
RealityCentre/ - goodies from SGI's RealityCentre in the UK
------------------------------
Subject: -7- The IRIS Performer WWW Pages in Silicon Surf
Date: 12 Dec 95 00:00:01 EST
Silicon Surf (http://www.sgi.com/) contains an archive of
Performer-related technical and promotional material in the
_Extreme Tech_ section.
http://www.sgi.com/Technology/Performer contains links
to further information regarding:
- What is IRIS Performer ?
- IRIS Performer 2.0 Technical Information
- IRIS Performer 2.0 Product Information
- IRIS Performer Friends, Goodies, & Free Stuff!
- The IRIS Performer Mailing List
- The IRIS Performer Anonymous FTP Archives
- The IRIS Performer Frequently Asked Questions (FAQ).
------------------------------
Subject: -8- The IRIS Performer Technical Report
Date: 12 Dec 95 00:00:01 EST
The IRIS Performer 2.0 Technical Report (IRIS-PERF-TR-10/95) is
available in hardcopy from your local Silicon Graphics sales
office. An electronic copy (Postscript format) is also available
via FTP from:
ftp://sgigate.sgi.com/pub/Performer/docs/pf2.0techreport/
------------------------------
Subject: -9- How does IRIS Performer relate to IRIS Inventor?
Date: 26 Jun 93 00:00:01 EST
The short answer is, Performer was designed for vis-sim, while
Inventor was designed to be more general purpose.
IRIS Performer is for developers who need to extract maximum
performance from SGI machines for visual simulation, virtual
reality, game development, and high-end CAD systems. Often these
applications need multi-processor Onyx systems with multiple
RealityEngine pipelines with a high degree of parallelism and
running at fixed frame rates.
Inventor is designed for maximum programmer productivity when
writing other kinds of 3D applications, like modelling, animation,
visualization, etc.
Both toolkits are general purpose enough that they could be extended
into the domain of the other, but the question you should consider is
"what is the *fundamental* goal of my graphics development?" If it's
portability to non-SGI systems, easy X-window system integration, or
handy graphic widgets, IRIS Inventor is for you. If it's brochure-
level performance in advanced graphic applications for the specific
domains listed above, then IRIS Performer would be the likely tool.
------------------------------
Subject: -10- What version of IRIS Performer should I use?
Date: 16 Oct 97 00:00:01 EST
The short answer is that IRIS Performer 2.0 is the latest
all-platform release and 2.1 is the InfiniteReality (all flavors -
Onyx, Onyx2, iR Reality) release. If you are doing development for
an application targeted primarily at an InfiniteReality graphics
platform using InfiniteReality features, you should buy 2.1. You
can run 2.1 on any platform running IRIX 6.2 or later, but its only
benefit over 2.0 was features for the InfiniteReality graphics
platform.
IRIS Performer also creates and ships binary compatible bug-fix
upgrades for the execution environment of the main releases. These
maintenance releases have a third field in their number string and
are binary compatible with the base release. These upgraded
execution environments include the optimized DSOs and demo
executables and are shipped with IRIX releases and made available
for older IRIX releases through patches. The following table lists
the latest versions of our releases and the version of IRIX that
they shipped with and the corresponding patch number.
Performer Maintenance Releases:
performer_eoe shipped in IRIX available in Patch for IRIX Releases
-----------------------------------------------------------------------
*** 2.0.4/2.1.2(*) 6.4 1696 6.2 and later
2.0.3/2.1.1(*) 6.3
2.0.2 1347 6.2 and later
2.0.1 6.2
(*) The 2.1.X upgrades are included as 2.1 compatibility subsystems
inside the corresponding 2.0.X version. This is done to allow upgrades
for both releases to ship inside IRIX.
(***) this is the latest maintenance version check it out!
All InfiniteReality systems (Onyx, Onyx2, ir Reality) running IRIX
6.2 or later should use IRIS Performer 2.1 (eoe and dev). Note
that Performer 2.1 was originally only officially supported on Onyx
InfiniteReality systems and is only of benefit on those system or
for doing development for those systems. Other systems and
projects not targeted at InfiniteReality should use 2.0 eoe and 2.0
dev, plus the latest eoe upgrade or patch as indicated above.
Patches available for IRIS Performer development subsystems: (also
see later section on patches)
There have are 2 patches available for the Performer 2.0
development subsystems (sample source code, header files, debug and
static libraries) that correspond to the 2.0.2 eoe maintenance
release:
patch 1392 IRIX 6.2 and later
patch 1414 for IRIX 5.3 (contains dev and eoe)
These patches are for the 2.0 development subsystems _only_. Do
not attempt to install them if running any other base release for
development.
------------------------------
Subject: -11- What patches should be used with IRIS Performer?
Date: Wed Sep 22 16:26:21 CDT 1999
performer_eoe:
6.4: No patches required for performer_eoe 2.0.4/2.1.2
6.3: Patch 1696 - updates Performer 2.0, 2.0.1, 2.0.3/2.1.1
to the 2.0.4/2.1.2 EOE shipped in IRIX 6.4
6.2: Patch 1696 - updates Performer 2.0 and 2.0.1,
to the 2.0.4/2.1.2 EOE shipped in IRIX 6.4
5.3: Patch 1414 - updates Performer 2.0 eoe & dev -> 2.0.2.
All versions of performer_eoe for 2.0[.X] are binary compatible.
All versions of performer_eoe for 2.1[.X] are binary compatible.
Patch 1696 updates all performer_eoe 2.0.x to 2.0.4 and all 2.1 to 2.1.2
Patch 1696 replaces patch 1347.
performer_dev:
All performer_dev 2.0 should be upgraded to at least performer_dev 2.0.2
for IRIX 6.2 and later IRIX releases.
6.4: Patch 1392 - updates Performer 2.0 DEV -> 2.0.2 DEV
6.3: Patch 1392 - updates Performer 2.0 DEV -> 2.0.2 DEV
6.2: Patch 1392 - updates Performer 2.0 DEV -> 2.0.2 DEV
5.3: Patch 1414 - updates Performer 2.0 eoe & dev -> 2.0.2.
Patch 1392 IS for the 2.0 development subsystems _only_.
Do not attempt to install it if running any other base release
for development.
performer_eoe 2.0.2 and 2.0.4 are both binary compatible with
performer_dev 2.0[.X]
All of the patches require a base subsystem from the IRIS Performer CD or
from IRIX to be loaded first.
Customers with SupportFolio online access can download patches from:
http://www.sgi.com/support/patch_intro.html
------------------------------
Subject: -12- What version of IRIS Performer am I currently running?
Date: 16 Oct 1997 00:00:01 EST
To find out what release of IRIS Performer is currently installed
on the system do:
% versions | grep performer
and you will see a list of all IRIS Performer subsystems that are
currently installed. Note that you might see execution
environments and compatibility DSOs for older releases of IRIS
Performer -- this is what allows you to run any IRIS Performer
executable, regardless of the development release you are currently
using.
To find out which version a given IRIS Performer DSO library is do:
% elfdump -L lib.so | fgrep IVERSION
and you will see the DSO version number of the library. Note: DSO
version numbers are NOT the same as IRIS Performer product release
numbers. DSO numbers are X.Y.Z where the X must change with each
change in binary compatibility, where the Y changes to signify a
binary compatible version, and the .Z is an additional tag. The
mapping of IRIS Performer releases to DSO numbers is:
IRIS Performer release DSO lib version
-------------------------------------------
1.0 sgi1.0
2.0 sgi2.0
2.0.1 sgi2.1
2.0.2 sgi2.2
2.0.3 sgi2.3
2.0.4 sgi2.4
2.1 sgi3.0
2.1.1 sgi3.1
2.1.2 sgi3.2
Each release of IRIS Performer includes the versioned DSO libraries
from previous releases for each binary compatible group. Upon
program startup, rld will find the proper version of the IRIS
Performer library for the current executable. These DSOs are
installed under /usr/lib/ and /usr/lib/Performer.
ex:
/usr/lib/libpf_ogl.so.2
/usr/lib/libpf_ogl.so.3
/usr/lib/libpf_ogl.so.4
% elfdump -L /usr/lib/libpf_ogl.so.2 | fgrep IVERSION
[34] IVERSION sgi2.4
To find out which version a dynamically linked IRIS Performer
executable was made with do:
% elfdump -L progname
and you will see a list of the DSOs required by the program and
their DSO version number.
------------------------------
Subject: -13- What are all of the released versions of IRIS Performer?
Date: 16 Oct 1997 00:00:01 EST
Performer 2.0.4: performer_eoe 2.0 bug fix upgrade, shipped with IRIX 6.4
[equivalent updates in patch 1696 for 6.2 and later]
Performer 2.1.2: performer_eoe 2.1 bug fix upgrade, shipped as
compatibility libs in 2.0.4 in IRIX 6.4 and patch 1696
Performer 2.0.3: performer_eoe 2.0 bug fix upgrade, shipped with IRIX 6.3
Performer 2.1.1: performer_eoe 2.1 bug fix upgrade, shipped as
compatibility libs in 2.0.3 in IRIX 6.3
Performer 2.1: InfiniteReality release, for all InfiniteReality systems
running IRIX 6.2 or later, (eoe and dev)
Performer 2.0.2: bug fix upgrade for Performer 2.0.1/2.0 eoe and dev,
shipped in patches 1347(eoe)+1392(dev) (for IRIX 6.x) or
patch 1414 (for IRIX 5.x)
Performer 2.0.1: bug fix upgrade for 2.0 EOE update only, shipped in
IRIX 6.2
Performer 2.0: All-platform release for IRIX 5.3 and later releases
IRIS Performer 1.2/IRIX5: (obsolete) For IRIX 5.2, 5.3, 6.0.1, 6.1
IRIS Performer 1.2/IRIX4: (obsolete) For IRIX 4.0.5(A-J) only
IRIS Performer 1.1: (obsolete) For IRIX 5.x only
IRIS Performer 1.0: (obsolete) For IRIX 4.x only
Patch 1696: performer_eoe updates Performer on IRIX 6.2 and 6.3 to
the 2.0.4/2.1.2 shipped in IRIX 6.4.
It updates 2.0.1, 2.0.2, 2.0.3 eoe to revs equiv to 2.0.4.
It updates 2.1, 2.1.1 eoe to revs equiv to 2.1.2.
Replaces 1347.
Patch 1414: performer 2.0 eoe & dev patch for IRIX 5.3 only
Patch 1392: performer_dev 2.0 patch for IRIX 6.2, 6.3, 6.4.
Patch 1347: performer_eoe 2.0.1 patch for IRIX 6.2 only
Historical/Background information:
Note that the above list is included only for completeness' sake.
Also note that you might not want "highest numbered" version of
Performer, you want the the highest maintenance rev of your main
release (2.1.X for InfiniteReality and 2.0 otherwise). Note that
maintenance releases have been done for both 2.0 and 2.1
simultaneously.
Systems running IRIX 6.2 or later should load the performer_eoe
IRIX cd, and performer_dev from the Performer 2.0 CD. Then load
the relevant patches as described below.
The N32 and N64 libraries in Performer 2.0 are not intended for
systems running IRIX 6.1. If you require N32 or N64 functionality,
you need to upgrade to 6.2 (or above) and use 2.0.1 (or above).
No further releases of Performer are planned for IRIX 4.x or 5.x.
Performer 1.2 was shipped for both 4.0.5 and 5.2 systems. If you
are using IRIS Performer 1.2, only install that version that is
appropriate for your machine. The IRIS Performer version is
indicated by the "IRIX4" or "IRIX5" string in each product name.
IRIX4 products should only be installed on 4.0.5 systems. IRIX5
products can be installed on 5.2, 5.3, 6.0.1, and 6.1 systems.
When a choice is possible between using Performer 1.2 with IRIX 5.x
or IRIX 4.0.5, IRIX 5.x is highly preferable. IRIX 5.3 is the
current operating system release and contains many bug fixes and
enhancements utilized by IRIS Performer. IRIS Performer 1.2/IRIX4
was intended only for users who are unable to upgrade to IRIX 5.x.
------------------------------
Subject: -14- Does IRIS Performer use IRIS GL or OpenGL?
Date: 12 Dec 95 00:00:01 EST
Performer 2.1 is OpenGL only, having bindings for O32 (32-bit)
OpenGL, N32 (32-bit) OpenGL, and N64 (64-bit) OpenGL.
IRIS Performer 2.0, 2.0.1, "2.0.2", 2.0.3, and 2.0.4 contain
bindings for O32 IRIS GL, O32 OpenGL, N32 OpenGL, and N64 OpenGL.
IRIS Performer 1.0, 1.1, and 1.2 use IRIS GL (32-bit).
------------------------------
Subject: -15- Is there a IRIS Performer file format?
Date: 26 Oct 93 00:00:01 EST
Yes. Performer "2.0.2", 2.0.3, 2.0.4, and 2.1 now include pfb (a
fast-loading binary database format) support in libpfpfb. It also
adds support of "pfa" format, a slow-loading ascii version of pfb.
The 'pfconv' program can be used to convert other file formats to
pfb.
Prior releases do not have a Performer-specific file format.
------------------------------
Subject: -16- What database file formats can IRIS Performer read?
Date: Thu Sep 30 16:55:07 CDT 1999
Performer "2.0.2", 2.0.3, 2.0.4, and 2.1 add support of the
following two formats, in addition to those available in Performer
2.0:
pfa: IRIS Performer ASCII format developed by Rob Mace
pfb: IRIS Performer BINARY format (very fast) developed by Rob Mace
IRIS Performer 2.0 and 2.0.1 contain direct import capabilities for:
3ds: AutoDesk 3DStudio binary data
bin: Minor SGI format used by powerflip
bpoly: Side Effects Software PRISMS binary
byu: Brigham Young University CAD/FEA data
dwb: Coryphaeus Software Designer's Workbench
dxf: AutoDesk AutoCAD ASCII format
flt11: MultiGen public domain Flight v11 format
flt14: MultiGen OpenFlight v14 format
gds: McDonnell-Douglas GDS things data
gfo: Minor SGI format (radiosity output)
im: Minor SGI format (IRIS Performer example)
irtp: AAI/Graphicon Interactive Real-Time PHIGS
iv: SGI OpenInventor / VRML 1.0
lsa: Lightscape radiosity solutions (ASCII)
lsb: Lightscape radiosity solutions (binary)
m: University of Washington mesh data
medit: Medit Productions medit modeling tool
nff: Eric Haines' ray tracing test data format
obj: Wavefront Technologies data format
post: Minor SGI format (example gridded terrain loader)
phd: Minor SGI format (polyhedra)
poly: Side Effects Software PRISMS ASCII data
pts: University of Washington point data
ptu: Minor SGI format (IRIS Performer example)
s1k: US ARMY SIMNET databases (Texas Instruments)
sgf: US NAVY standard graphics format
sgo: Minor SGI format
spf: US NAVY simple polygon format
sponge: Sierpinski sponge 3D fractal generator
star: Yale University compact star chart data
stla: 3D Structures Stereolithography (ASCII)
stlb: 3D Structures Stereolithography (binary)
sv: Format of John Kichury's i3dm modeler
tri: University of Minnesota Geometry Center data
unc: University of North Carolina data
Several other file formats will be available via translators:
via Acuris Corporation translators (to OpenInventor):
iges Old standard computer aided design interchange format
alias Alias Research animation system data
3ds AutoDesk 3DStudio
obj Wavefront Technologies OBJ format
dxf AutoDesk AutoCAD format
softimage Microsoft/Softimage animation system data
via Clarus AB translators:
step New standard computer aided design interchange format
vertigo Vertigo animation system data
via ViewPoint, http://www.viewpoint.com/, translators (to OpenInventor):
3D Studio, BRender, Alias polyset, CAD-3D, CADL, DXF, Imagine,
Inventor, LightWave objects and scenes, MovieBYU, Haines NFF,
Sense8 NFF, POV-Ray, Pro/ENGINEER, Prisms, RAW, RenderWare,
Sculpt, SGI spin, Soft F/X, stereolithography, StyleGuide,
Swivel, GDS "things", trueSpace, Vertigo, Vista DEM, VideoScape
and Wavefront formats.
IRIS Performer 1.2 includes loading utilities and file loaders for:
- The SGI .bin, .sgo, .gfo, .poly, and .ptu formats
- IRIS Inventor's .iv format.
- Coryphaeus' Software .dwb format.
- Software Systems (MultiGen Inc) Version 11, 13, and 14 .flt
- The SuperViewer .sv format used in I3DM
- Lightscape Graphics Software's .lsa and .lsb formats
- Autodesk's AutoCAD .dxf format
- Miscellaneous formats (.gfo, .irtp, .stla, .stlb).
For source code to loaders for MultiGen .flt versions greater than
11, contact MultiGen, Inc at (408) 556-2600.
IRIS Performer 1.0 and 1.1 include database loaders for MultiGen v11
"flt", SGI "bin", and SGI "obj" formats.
------------------------------
Subject: -17- Is there an IRIS Inventor file reader for IRIS
Performer?
Date: 12 Dec 95 00:00:01 EST
Yes. IRIS Performer 2.x ships with a fully-functional Open
Inventor 2.0 file loader.
IRIS Performer 1.2 ships with a minimal .iv reader that will read a
subset of the IRIS Inventor 1.0 format.
A port of the more robust 2.x reader for Open Inventor files is
also available for Performer 1.2, in the Performer FTP Archives:
ftp://sgigate.sgi.com/pub/Performer/src/pfiv1.6.tar.Z
No Inventor file reader exists for Performer 1.0 or 1.1.
------------------------------
Subject: -18- What are the .tlf files used by the Performer Town and
Village?
Date: 8 Apr 94 00:00:01 EST
They are encrypted .flt files of the Town and Village database.
Only the "demo" version of perfly shipped with RealityEngine
systems in demos.sw.visualization can read these files.
Unencrypted versions of the Town and Village databases are included
in the performer_friends.sw.town subsystem of Performer 1.2 and 2.0.
------------------------------
Subject: -19- What are the minimum requirements for using IRIS
Performer?
Date: 12 Dec 95 00:00:01 EST
IRIS Performer 2.0 is the all platform release and requires IRIX 5.3
or later IRIX releases.
Binary compatible upgrade patches are available and recommended.
IRIS Performer 2.1 requires IRIX 6.2 or a later IRIX release.
IRIS Performer 2.1 is intended for running on or developing for the
InfiniteReality graphics platform.
IRIS Performer 2.0.4 (eoe) requires IRIX 6.2 or a later IRIX release
and shipped in IRIX 6.4 and IRIS Performer patch 1696
IRIS Performer 2.0.3 (eoe) requires IRIX 6.2 or a later IRIX release
and is shipped in IRIX 6.3.
IRIS Performer 2.0.2 (eoe) requires IRIX 6.2 and later and is
shipped in IRIX 6.2 and was shipped in IRIS Performer patch
1392 and has now been obsoleted by IRIS Performer 2.0.4 in patch 1696.
IRIS Performer 2.0.1 (eoe) requires IRIX 6.2 or a later IRIX release
was shipped in IRIX 6.2.
Patch 1347 (eoe 2.0.2) requires IRIX 6.2 or later IRIX releases
and is obsoleted by patch 1396.
Patch 1396 (eoe pf2.0.4) requires IRIX 6.2 or later IRIX releases
Patch 1392 (dev pf2.0.2) requires IRIX 6.2 or later IRIX releases
Patch 1414 (eoe+dev pf2.0.2 for IRIX 5.3) is only for IRIX 5.3.
IRIS Performer 1.2/IRIX5 requires IRIX 5.2 or later IRIX release.
IRIS Performer 1.2/IRIX4 requires IRIX 4.0.5. Because IRIX 4.0.5F
added several new Graphics Library (GL) calls to support
RealityEngine features, any application that uses GL routines or
tokens found only in 4.0.5F and later, will not run properly under
4.0.5C and earlier releases.
------------------------------
Subject: -20- Binary Compatibility on different machines
Date: 12 Dec 95 00:00:01 EST
Applications compiled with IRIS Performer 2.0 using IRIX 5.3 will
run unmodified across all SGI platforms. For best performance, use
IRIS GL with RealityEngine and other pre-Impact systems and use
OpenGL for Impact and post-Impact graphics hardware.
OpenGL-oriented systems provide the IGLOO (Iris GL on OpenGL)
portability layer to execute IRIS GL applications, but it is not
the maximum performance route. Performance oriented developers are
advised to generate both IRIS GL and OpenGL executables, by linking
with the API-compatible IRIS Performer 2.0 IRIS GL and OpenGL
libraries. In this way, you can assure optimum performance across
present and future graphics systems. For OpenGL development on
RealityEngine with IRIX 5.3, patch 154 (or a superseding patch) is
recommended for performance and features.
IRIS Performer 1.2/IRIX5 contains a single version of libpr for all
machines. Applications built with Performer 1.2 for Irix 5.2 are
fully compatible across machines and can run on any graphics type
without relinking.
In IRIS Performer 1.0, 1.1, and 1.2/IRIX4, libpr is platform-
specific with one of two versions installed depending on whether
the machines is a RealityEngine or not. Binaries linked on
non-RealityEngine machines will run on a RealityEngine, but not all
features will be available.
------------------------------
Subject: -21- Binary Compatibility on different releases
Date: 17 Oct 97 00:00:01 EST
o Compatibility issues with previous Performer releases:
IRIS Performer release have a number of 3 fields: Major.Minor.Maint
Maintenance releases are binary compatible with all versions of
the same Major.Minor base release. For example, 2.0.1, 2.0.2, 2.0.3
and 2.0.4 are all binary compatible with each other and are
all binarcy compatible with their base release, 2.0. Maintenance
releases contain bug fixes and the highest maintenance number will
be the most recent release. Different Major.Minor releases are not
binary compatible; ie: IRIS Performer 2.0 is not binary compatible
with IRIS Performer 2.1. For this reason, IRIS Performer releases
include compatibility libraries from previous releases (properly
versioned and suffixed for the IRIX environment) so that old
IRIS Performer applications will continue to run without re-linking.
Performer compatibility issues with IRIX 5.3:
Applications created with IRIS Performer 2.0 using IRIX 5.3 also
run under IRIX 6.1 and later IRIX releases in 32-bit mode. The
32-bit applications created using IRIX 5.3 will not make use of
64-bit address space and other MIPS III/IV features provided by the
IRIS Performer N32 and N64 development environment under IRIX 6.2
and later operating system releases.
Note that applications built on an IRIX 6.1 or 6.2 systems are not
guaranteed to run properly on 5.3 systems, due to changes in
structures used by system libraries. (This is true even for
applications that do not use IRIS Performer-- applications built on
later versions of IRIX may not run on earlier ones). Therefore to
produce an O32 executable that will run on all SGI systems 5.3 and
later, the compiling must be done on an IRIX 5.3 system.
Performer compatibility issues with IRIX 6.1:
Applications created with IRIS Performer 2.0 under IRIX 6.1 can be
compiled and linked for 32-bit IRIX 5.3-style execution (known as
Old 32-bit mode, or O32) only. IRIS Performer programs built for
the two new executable types (N32 and N64) are not operable on
pre-6.2 systems -- specifically, they will not run on IRIX 5.3 or
6.1 systems.
O32 IRIS Performer programs will run on IRIX 6.1. However, the
OpenGL development environment of IRIX 6.1 is not as full featured
as the 32-bit OpenGL of IRIX 5.3 or IRIX 6.2. This can cause both
low-performance and lack-of-feature problems for developers
creating OpenGL applications. For this reason, developers are
advised to build only IRIS GL applications on IRIX 6.1 systems or
to upgrade to IRIX 6.2 for access to its enhanced 32-bit and 64-bit
OpenGL development environment.
Performer compatibility issues with IRIX 6.2:
IRIS Performer 2.0 and 2.1 are compatible with IRIX 6.2 and later
IRIX relases. Applications can be developed for all three execution
modes: O32, N32, and N64.
The IRIX 6.2 32-bit and 64-bit OpenGL implementations have the
RealityEngine feature extensions and performance enhancements found
in IRIX 5.3. For this reason, developers are urged to use IRIX 6.2
or later rather than IRIX 6.1 for OpenGL development. As mentioned
above, IRIS Performer applications built in either N32 or N64 mode
will not run on IRIX 5.3 or 6.1 systems, and, in general,
applications should not be run on earlier versions of IRIX than the
machine on which they are compiled.
Applications using Performer 1.2/IRIX5 are binary compatible with
machines running Irix 5.2, 5.3, 6.0, and later IRIX releases
without relinking.
IRIS Performer 1.0 requires IRIX 4.0.5 or later. Because IRIX
4.0.5F added several new GL calls to support RealityEngine
features, an application that uses GL routines or tokens found only
in 4.0.5F and later does not run properly under 4.0.5, 4.0.5B, or
4.0.5C. When run on these earlier IRIX releases, an IRIS Performer
1.0 application making calls to GL functions or using GL tokens
that are undefined in the run-time environment cause run-time
errors or undefined behavior.
An IRIS Performer 1.0 binary compiled and linked under IRIX
releases earlier than 4.0.5F will run under IRIX 4.0.5F and later,
but some RealityEngine features are not directly accessible to the
application. An application can still access RealityEngine
features supported automatically or explicitly through IRIS
Performer when linked with IRIS Performer shared libraries.
Running a IRIS Performer application built with IRIX 4.0.5 on IRIX
5.X is not recommended. In particular, multiprocess applications
cannot take advantage of all processors. Also, because IRIX 4.0.5's
relaxed shared memory accounting was replaced by a despotic and
stricter regime under IRIX 5.2, a Performer application built on
4.0.5 will need a much larger amount of swap space to be allocated up
front unless PFTMPDIR is used to specify a memory mapped file.
------------------------------
Subject: -22- Guaranteeing Real Time performance
Date: 8 Apr 94 00:00:01 EST
- Run as root so that Performer can lock your process to
a particular CPU (if using pfuLockCPU) and give it a
non-degrading priority.
- Be sure to kill any clocks, gr_osview, or other tools that may
wake up and draw themselves, so as to avoid graphics context
switches.
- When multiprocessing, make sure the executable is on a local file
system.
- There is a new real-time kernel directive for Onyx/Challenge
processors for directing system interrupts away from real-time
processors.
In the file /var/sysgen/system/irix.sm, Search for NOINTR and
below the comment explaining NOINTR, add the line
NOINTR: 1 2 3 4 ..etc..
where you list the CPUs that you intend to do real-time
processing on. Then reboot. This can be done on 5.2+
Onyx/Challenge systems but wasn't covered in the base IRIX5
documentation. Be sure -not- to specify CPU 0, as you will want
it to be available for necessary interrupts.
- With IRIS GL, real-time performance can only be guaranteed if you
have one window rendering at a time, per pipe.
If more than one application is rendering to the same hardware
pipeline, the (hardware) graphics pipe has to switch back & forth
between each GL window's context several hundred times per
second. This is horribly inefficient and the graphics pipe will
instruct the "other" process to block while its context is
switched out.
- Since having other (cpu-based) applications running can also
effect real-time performance, it's sometimes desirable to
minimize the number of daemons and other processes. If you have
problems achieving real-time behavior, try the pfuLockCPU in
libpfutil. You might also try turning off the desktop support
and other daemons that are not crucial to your application,
e.g.:
% touch ~/.disableDesktop
or
% mkdir ~/.desktop-<machinename>
% touch ~/.desktop-<machinename>/nodesktop
and for total removal do:
% chkconfig desktop off
% chkconfig objectserver off
% chkconfig directoryserver off
% chkconfig fontserver off
% chkconfig soundscheme off
------------------------------
Subject: -23- How do I make GL calls from within a IRIS Performer
program?
Date: 26 Oct 93 00:00:01 EST
GL calls can only be made from a process that has a GL context. In
multi-process Performer applications only the draw process has GL
context, so you must make your GL calls in a function called in the
draw process.
The pipe initialization callback, draw function callback, and node
draw callbacks are all executed in the draw process.
In an application that only will ever run single-process, GL calls
can be made from anywhere in the program, but this is considered a
dangerous practice.
To set up a pipe initialization callback, see the pfInitPipe()
manpage. To set up a draw function callback, see the
pfChanDrawFunc() manpage. To set up a node draw callback, see the
pfNodeTravFuncs() manpage.
------------------------------
Subject: -24- How do I overlay graphics on top of my Performer scene?
Date: 06 Oct 93 00:00:01 EST
Typically this is done to implement a heads-up display (HUD).
In the draw function callback, the basic algorithm is:
save state with pfPushState()
disable textures, fog, & lighting with pfBasicState()
save & clear projection matrix
ortho2()
save & clear modelling matrix
draw()
restore modelling matrix
restore projection matrix
restore state with pfPopState()
Or, you can draw your static info in the overlay planes and only
redraw it when the window receives a REDRAW event (moved, resized,
etc.). Changing between drawing to the overlays and drawing to
regular bitplanes takes a big hit.
For things that need to be updated real-time, draw() would consist
of:
zfunction(ZF_ALWAYS);
zwritemask(0x0);
draw HUD stuff
zfunction(ZF_LEQUAL);
zwritemask(0xffffffff);
------------------------------
Subject: -25- What is the difference between phases FREE, FLOAT, and
LOCK?
Date: 26 Oct 93 00:00:01 EST
PFPHASE_FREE_RUN wakes the application and draw processes up on the
next video field boundary after the draw finishes. i.e. it's
Performer's version of the usual run as-fast-as-I-can or
as-slow-as-I-must mode that most simple graphics programs use.
PFPHASE_FLOAT wakes the application up only on frame boundaries,
i.e. time = n*(1/frame_rate). However, the draw process "floats"
with respect to the frame rate and wakes up on the next possible
field boundary and then does a swapbuffers() when it's done,
regardless of whether it finished drawing in time for the desired
frame rate. Hence you see every frame that's drawn to the
backbuffer, but it may not appear at exactly the time for which it
was planned. If you never frame extend, it behaves like
PFPHASE_FIXED. Latency is variable.
PFPHASE_LOCK wakes the application and draw up only on frame
boundaries and only swaps on frame boundaries. The advantage is
that each new image always appears at precisely the time for which
it was rendered. The disadvantage is that if the draw runs even
slightly over a frame time, you skip that entire frame and are
stuck with an outdated picture for a frame. Latency is fixed.
For more information see the pfPhase() man page or section 7.1.2 of
the PFPG.
------------------------------
Subject: -26- Use of PFTMPDIR to configure shared memory
Date: 12 Dec 95 00:00:01 EST
IRIS Performer requires shared memory and uses a memory-mapped
file, the location of which depends on the value of the PFTMPDIR
environment variable:
If PFTMPDIR is not set, Performer uses /dev/zero as the default.
Running an application in this configuration:
- Uses swap space
- Does not require disk space until main memory is exhausted
- Is faster than using a regular memory mapped file via PFTMPDIR
- Causes IRIX to kill the process(es) and log an error to the
console if the application runs out of space for shared memory in
the swap partition.
If PFTMPDIR is set, Performer creates files in the specified
directory. Running an application in this configuration:
- Requires disk space even before main memory is exhausted
- Is slower than /dev/zero because it touches the disk
- Produces appropriately sized core dump files with no limit set by
IRIS Performer
- Might cause a core dump from a segmentation violation inside
pfMalloc if the application runs out of space for shared memory
in the file system containing PFTMPDIR
- PFTMPDIR should be set only to a directory on a local file system.
------------------------------
Subject: -27- Which rendering primitives does IRIS Performer support?
Date: 12 Dec 95 00:00:01 EST
Points (PFGS_POINTS),
Independent line segments (PFGS_LINES),
Connected line strips (PFGS_LINESTRIPS),
Flat connected line strips (PFGS_FLAT_LINESTRIPS),
Independent Triangles (PFGS_TRIS),
Independent quadrilaterals (PFGS_QUADS),
Connected triangle strips (PFGS_TRISTRIPS),
Flat Connected triangle strips (PFGS_FLAT_TRISTRIPS),
Independent n-sided polygons (PFGS_POLYS).
See the pfGeoSet(3pf) man page for more information.
------------------------------
Subject: -28- How do I do triangle meshes in Performer?
Date: 12 Dec 95 00:00:01 EST
You must change your triangle meshes to triangle strips by hand.
In Performer 2.0, pfdMeshGSet (pfuMeshGSet in 1.2) does this for
you.
------------------------------
Subject: -29- ================= Known Problems =================
Date: 8 Apr 94 00:00:01 EST
------------------------------
Subject: -30- Video Rate sometimes reported incorrectly
Date: 12 Dec 95 00:00:01 EST
The video rate used by IRIS Performer for frame rate control is
computed at application startup on some machines and is not always
exactly correct. If this is a problem, the video rate can be set
with pfVideoRate.
------------------------------
Subject: -31- Problems with Performer Town or Village demos
Date: 12 Dec 95 00:00:01 EST
- IRIX 5.0: It was reported that perfly would cause an Onyx RE or
VTX to hang. This was fixed in 5.0.1.
- IRIX 5.0.1: perfly would generate floating point exceptions due
to a bug in the font manager library (libfm). This was fixed in
5.1.
- IRIX 5.2/5.3 Kernel Panic: Certain IRIX patches were
incompatible with Performer and would cause the Town or Village
demos to panic the system if run as root. The error message
was:
PANIC: CPU 3: Stack Extension Page is inconsistent
Double PANIC: CPU 0: Stack Extension Page is inconsistent 111
at block 0
In IRIX 5.2, the crash occurs with patches 125 and 139.
In IRIX 5.3, the crash occurs with patch 158.
- Jerky forward motion. This is caused by an uneven frame rate.
The Performer town demo is fill limited and typically can not
maintain a steady 30Hz.
This can also occur if perfly is not being run as root. When run
by root, Performer applications will set nondegradable priorities
for their processes to improve the consistency of the run-time
behavior.
This same problem is also caused by the user having another
GL-based application (like gr_osview) running at the same time.
- Ghosting. A true FAQ is why multiple images of objects like
trees, house edges, the horizon, etc. are seen as the viewer
turns. This is a form of "temporal aliasing" and is an attribute
of having a frame rate which is less than the video refresh
rate.
The problem is that a single image is scanned out onto the
monitor several times before being changed. The repetition of a
frame means that the image is temporally inaccurate for motion.
Real moving objects do not stay in one place for a couple frame
times and then move.
What's actually happening is that your eye is following an
object, moving with the same angular velocity, which keeps the
image stationary on the retina. Between two video refreshes of
the same frame, your eye has moved, but the image on the screen
has not. Consequently the image of the second frame appears at a
different location on the retina, and you see a "ghost" image.
So a simulation running at 20Hz update on a display refreshing at
60Hz, the object will appear tripled. On large objects such as
horizon silhouette, the effect manifests itself as multiple
edges.
------------------------------
Subject: -32- Antialiasing
Date: 8 Apr 94 00:00:01 EST
When it is not multisampling, pfAntialias can significantly degrade
performance. Specifically, on non-RealityEngine systems, use
pfAntialias only for lines and points.
------------------------------
Subject: -33- Coplanar Polygons & pfDecal on certain platforms
Date: 8 Apr 94 00:00:01 EST
pfDecal works only on machines that support the stencil or
displacepolygon command. The default decaling mode for PFDECAL_BASE
now uses displacepolygon instead of stencil. This can significantly
improve rendering performance but can result in visual anomalies
where layer polygons incorrectly "poke" through other geometry. If
you wish the old behavior then specify the PFDECAL_BASE_HIGH_QUALITY
token.
------------------------------
Subject: -34- Networked graphics (DGL & GLX)
Date: 12 Dec 95 00:00:01 EST
libpf-based applications in IRIS Performer 1.0, 1.1, 1.2, and 2.0
do not support applications that use networked GL (DGL). However,
applications using libpr only can use DGL.
This bug/problem is a side-effect of having vertical retrace
counter control, which is only available on VGX, VGXT, VTX, Reality
Engine, Reality Engine 2, Elan, and Extreme graphics systems.
OpenGL-based Performer 2.0 applications display properly to remote
systems via the GLX X server extension.
------------------------------
Subject: -35- Transparency
Date: 12 Dec 95 00:00:01 EST
pfTransparency works only on machines that support either
blendfunction or multisampling.
Sometimes users report that their transparency seems quantized. This
is not a bug -- Performer defaults to using Multisample transparency
(msalpha) when multisampling is enabled, instead of using the
"standard" (blendfunction) transparency mechanism.
Multisample transparency is faster but has much less resolution, and
so less quality. Standard transparency using blendfunction is
slower, but the quality is very good.
To force Performer to use higher-quality (but slower) transparency
when multisampling,
1.0/1.1: pfGStateMode (gstate, PFSTATE_TRANSPARENCY, 2);
1.2/2.0: pfGStateMode (gstate, PFSTATE_TRANSPARENCY, PFTR_HIGH_QUALITY);
aka PFTR_BLEND_ALPHA
In 1.0/1.1 the BLEND_ALPHA token was not exposed, but just use '2'.
Be sure to revisit this code when you port to 1.2, as the token has
changed.
See the pfTransparency(3pf) man page for more details.
------------------------------
Subject: -36- Gangdraw and cursor loading
Date: 12 Dec 95 00:00:01 EST
Loading the cursor with ganged swapbuffers (external swapready
wire) hangs graphics. Workaround: don't load the cursor and use a
full screen window when using ganged swapbuffers.
------------------------------
Subject: -37- Frame control on low- and mid-range machines
Date: 8 Apr 94 00:00:01 EST
Frame control on low- and mid-range machines: Currently, the video
clock (pfInitVClock, pfGetVClock, pfVClockSync) is supported only
on systems with VGX, VGXT, RealityEngine, RealityEngine2, Elan, XS,
Extreme, and Impact graphics hardware. On other systems,
pfVClockSync returns immediately. Because libpf normally uses
pfVClockSync for frame rate control, frame control is not rigorous
on other platforms.
------------------------------
Subject: -38- Timing on pre-1992 platforms
Date: 8 Apr 94 00:00:01 EST
Several libpf functions require high-resolution timing information.
On most recent machines (Indy, Indigo, Indigo2, 4D/35 and Onyx) and
PowerSeries or Crimson machines with IO3 boards, IRIS Performer
uses special hardware counters with sub-microsecond resolution.
(The IO3 board was standard on Crimson and later 4D/300 and 4D/400
machines. You can check for it with the hinv(1M) command.)
On older platforms, for example, those with IO2 boards, the
time-of-day clock is used, which, by default, has a 10 ms
resolution. This resolution is inadequate for many libpf functions,
including animation sequences (pfSequence), graphics load
computation (pfChanStress), and the display of accurate channel
statistics (pfDrawChanStats). On these machines, you may want to
enable fast timers using systune(1M) to set the fasthz variable.
See the man page for timers for more information. Frame rate
control is poor on machines that lack both a fast clock and the
video clock used by pfVClockSync.
------------------------------
Subject: -39- 2.0 Warnings from ld when building on IRIX 6.2
Date: 12 Dec 95 00:00:01 EST
When building executables on IRIX 6.2 and linking directly using ld
rather than implicitly via CC, an alarming number of warnings about
tables that are defined in multiple .so's may be printed. These are
harmless but the appropriate compiler option to disable the warning
has not yet been identified. The problem does not occur when
linking with CC, which is identical in function and serves as an
effective workaround.
------------------------------
Subject: -40- 2.0 Bug OpenGL functions missing when building static
executables
Date: 12 Dec 95 00:00:01 EST
When building static OpenGL executables in IRIX 5.3 installed it
may be necessary to specify the "-ignore_unresolved" option to ld
since not all OpenGL extensions used in Performer are available on
all platforms and OS versions. You may see warnings for the
unresolved symbols of OpenGL extensions that are not present on the
current system, but the executable will still successfully link.
------------------------------
Subject: -41- 2.0 Bug Z buffer problems when moving windows on 5.3
EXtreme
Date: 12 Dec 95 00:00:01 EST
When moving a window on Extreme graphics under IRIX 5.3, in some
clear modes the Z-buffer may not be updated properly until a full
czclear() operation is performed.
------------------------------
Subject: -42- 2.0 Bug Use of more than 512 simultaneous textures
Date: 12 Dec 95 00:00:01 EST
When more than 512 textures are used in either IRIS GL or OpenGL
the hardware and or host-side software may become confused and in
some cases, may falter completely and terminate the application.
This is a graphics library limitation.
------------------------------
Subject: -43- 2.0 Bug IRIS GL on dual-head systems
Date: 12 Dec 95 00:00:01 EST
IRIS GL based Performer executables encounter difficulties when
executing on dual-head Indigo systems. This problem is not present
in OpenGL applications.
------------------------------
Subject: -44- 2.0 Bug Resizing of pfPipeWindows in MP X apps
Date: 12 Dec 95 00:00:01 EST
Dynamic resizing of pfPipeWindows when multi-processed and using X
windows (IRIS GLX or OpenGL/X) when an alternate framebuffer
configuration window is selected (such as the fill statistics
window in OpenGL/X perfly) can cause channel viewports to be
confused when the alternate framebuffer configuration window is
de-selected (such as disabling the fill statistics in perfly when
running with X windows).
------------------------------
Subject: -45- 2.0 Bug Applying frustums transformed by
pfOrthoXformFrust
Date: 12 Dec 95 00:00:01 EST
pfApplyFrust() does not properly apply a frustum which has been
transformed with pfOrthoXformFrust(). Instead, the canonical
frustum whose eye is at the origin and is looking down the +Y axis,
is applied.
------------------------------
Subject: -46- 2.0 Bug pfFlatten with pfCycleBuffer attribute arrays
Date: 12 Dec 95 00:00:01 EST
pfFlatten() is broken for pfGeoSets with pfCycleBuffer attribute
arrays. A core dump is likely.
------------------------------
Subject: -47- 2.0 Bug Sorting lights with pfChanBinSort()
Date: 12 Dec 95 00:00:01 EST
The PFSTATE_LIGHTS sorting key for the PFSORT_BY_STATE mode of
pfChanBinSort() is not yet implemented.
------------------------------
Subject: -48- 2.0 Bug OpenGL disables back material modes
Date: 12 Dec 95 00:00:01 EST
Although Performer supports it, OpenGL does not support different
material color modes for front and back materials. When Performer
encounters this case, it disables the material color mode for the
back material.
------------------------------
Subject: -49- 2.0 Bug CPU statistics in IRIX 6
Date: 12 Dec 95 00:00:01 EST
Statistics: The PFSTATSHW_CPU pfStats statistics class for
accumulation of statistics on CPU usage are not yet implemented for
IRIX6 operation (64bit or 32bit).
------------------------------
Subject: -50- 2.0 Bug pfdLoadFile_flt FLT loader in IRIX 6
Date: 12 Dec 95 00:00:01 EST
The FLT loader under 64bit operation may core dump.
------------------------------
Subject: -51- 2.0 Bug hello sample program in IRIX 6
Date: 12 Dec 95 00:00:01 EST
The src/pguide/libpf/C/hello sample program may core dump under
64bit operation.
------------------------------
Subject: -52- 2.0 Bug Forked X input handing in IRIX 6.2
Date: 12 Dec 95 00:00:01 EST
On beta versions of 6.2 some problems were experienced with
handling X input in an additional forked process. For this reason,
the perfly sample application has a conditional compilation
construct to use the non-forked X input handling option of the
libpfutil X input handling utilities when compiled under IRIX6. You
may find this to not be necessary.
------------------------------
Subject: -53- 2.0 Bug Intersections with pfBillboard nodes
Date: 12 Dec 95 00:00:01 EST
Intersection testing of line segments (pfNodeIsectSegs) against
geometry in pfBillboard nodes is not yet implemented; only the
bounding sphere of the entire pfBillboard is available.
------------------------------
Subject: -54- 2.0 Bug Channel fade LOD attributes & mixed gfx configs
Date: 12 Dec 95 00:00:01 EST
Channel fade LOD attributes are set in the application process. The
existence of multisample, required for fade LOD, is tested at the
time that the attributes are set with pfChanLODAttr. This test for
multisample uses the application process window system connection
(pfOpenWSConnection) or else the DISPLAY environment variable to
select a screen for determining graphics configuration, instead of
testing the current window of the pfChannel. In a multipipe
environment where one graphics pipeline has multisample and one
does not, the application process needs to have a window system
connection or DISPLAY that points to the pipeline with multisample,
in which case the non-multisample pfChannels will try to use fade
LOD. In a multi-window environment, windows without multisample on
a system with multisample will try to use fade LOD.
------------------------------
Subject: -55- 2.0 Bug libpfui C API incomplete
Date: 12 Dec 95 00:00:01 EST
Libpfui has both a C API and a C++ API. The C API is actually
wrappers around the C++ API and is not complete.
------------------------------
Subject: -56- 2.0 Bug libpfdb pfdLoadFile_dxf incomplete
Date: 12 Dec 95 00:00:01 EST
The DXF loader does not fully support the format.
------------------------------
Subject: -57- 2.0 Bug libpfdb pfdLoadFile_sgo incomplete
Date: 12 Dec 95 00:00:01 EST
The SGO loader does not support triangle strips
------------------------------
Subject: -58- 2.0 Bug IRIS GL perfly on Indy
Date: 12 Dec 95 00:00:01 EST
The background of the GUI panel is influenced by the loaded
database. Additionally, fill statistics are not supported on Indy
under IRIS GL and will cause flashing and error messages to
stderr.
------------------------------
Subject: -59- 2.0 Bug pguide/libpf/C/pipewin sample program
Date: 12 Dec 95 00:00:01 EST
The overlay text is only drawn in IRIS GL and does not get properly
redrawn when the window size is changed.
------------------------------
Subject: -60- 2.0 Bug pguide/libpf/C/lpstate sample program
Date: 12 Dec 95 00:00:01 EST
The lpstate.c example for demonstrating pfLPointStates uses
sophisticated texturing capabilities that may not yet work on the
IMPACT, Extreme, or Indy graphics platforms.
------------------------------
Subject: -61- 2.0 Bug pfInitClock() and Video Rate on 250MHz IMPACT
Date: 12 Dec 95 00:00:01 EST
The clock period determined by pfInitClock() on 250MHz IMPACT
systems is apparently inconsistent with the true clock period. It
seems that the actual clock period is that of a 200MHz system.
Consequently, pfGetTime() will return a time that is .8 (200/250)
that of the true time.
Among other things, this invalidates the calculations done by
Performer to determine the current video rate.
As a workaround, you can specify an alternate clock period with the
PFCLOCKPERIOD environment variable. If set, PFCLOCKPERIOD
specifies the clock period, in picoseconds, to be used by
pfInitClock(). For proper behavior on 250MHz IMPACT systems, use
40000 for the period.
------------------------------
Subject: -62- 1.2 Bug Billboard normals and intersections
Date: 8 Apr 94 00:00:01 EST
During rendering, pfBillboard normals are not affected by the
transformation applied to make the geometry follow the eye.
Intersection testing of line segments (pfSegsIsectNode) against the
pfGeoSet's geometry and bounding box are not yet implemented; only
the bounding sphere of the entire pfBillboard is available.
------------------------------
Subject: -63- 1.2 Bug Incompatibility with IRIX 6.1 XFS
Date: 20 Nov 95 00:00:01 EST
Performer 1.2 contains a bug that prevents the use of an IRIX 6.1
XFS filesystem (the replacement for the older EFS) for Performer
shared memory and semaphores. There are a number of workarounds:
1) Use an EFS root filesystem
2) set PFTMPDIR to an EFS file system
3) reorder the device types in the kernel configuration
files and build a new kernel.
This problem is fixed in Performer 2.0.
------------------------------
Subject: -64- 1.2 Bug Billboards with multiple pfGeoSets
Date: 8 Apr 94 00:00:01 EST
Using pfBillboards with more than one pfGeoSet sometimes causes a
segmentation violation during the first cull traversal. Workaround:
use only a single pfGeoSet per pfBillboard at some cost in
performance.
------------------------------
Subject: -65- 1.2 Bug Flattening transformation hierarchies
Date: 8 Apr 94 00:00:01 EST
pfFlatten does not work properly on pfGeodes that share pfGeoSets
with other pfGeodes.
------------------------------
Subject: -66- 1.2 libpf Bug Hang on Exit, 5.2 VGX
Date: 8 Apr 94 00:00:01 EST
On VGXT running 5.2, calling pfExit when the phase is PFPHASE_LOCK or
PFPHASE_FLOAT can leave an inactive window and DRAW process.
Workaround: switch to PFPHASE_FLOAT or PFPHASE_FREE before exiting or
kill -9 <pid> afterwards.
------------------------------
Subject: -67- 1.2 libpf Cull with overlapped draw latency
Date: 8 Apr 94 00:00:01 EST
When running PFPHASE_LIMIT or PFPHASE_FREE, the draw can start late
resulting in higher latency.
------------------------------
Subject: -68- 1.2 libpf Cull with overlapped draw hang
Date: 8 Apr 94 00:00:01 EST
When running PFPHASE_LIMIT or PFPHASE_FREE, with processes locked and
non-degrading priorities, it is possible to lock out the X server and
hang the system.
------------------------------
Subject: -69- 1.2 libpf Transparency Sorting
Date: 8 Apr 94 00:00:01 EST
When the PFCULL_SORT mode of pfChanTravMode is set, transparent
objects are drawn after all opaque geometry. However, transparent
objects are not sorted back to front among themselves, so visual
anomalies can result when using blended transparency. Workaround:
use multisample transparency (PFTR_MS_ALPHA), if available.
------------------------------
Subject: -70- 1.2 libpf Multiple EarthSky fog
Date: 8 Apr 94 00:00:01 EST
When using multiple pipes which share pfEarthSky fog set by
pfESkyFog, the fog may appear to change densities and flash.
Workaround: to guarantee that pfClearChan is not called
simultaneously by more than one pipe. This may be accomplished with
a hardware spin lock (see usnewlock)
------------------------------
Subject: -71- 1.2 libpf Bug Limit Phase
Date: 8 Apr 94 00:00:01 EST
The PFPHASE_LIMIT mode of pfPhase only works when the draw stage is
configured as a separate process. For example, the PFMP_APP_CULLDRAW
mode to pfMultiprocess specifies that the cull and draw stages are
combined into a single process and so will not be affected by a LIMIT
phase.
------------------------------
Subject: -72- 1.2 libpr Highlighting when using wireframe
Date: 8 Apr 94 00:00:01 EST
Using highlighting when in wireframe mode can cause random,
flickering, or otherwise misbehaved polygons.
------------------------------
Subject: -73- 1.2 libpf APPCULLDRAW does not honor LIMIT/FLOAT/LOCK
phases
Date: 8 Apr 94 00:00:01 EST
When in PFMP_APPCULLDRAW mode, both FREE_RUN and LIMIT act the same;
as do FLOAT and LOCK.
------------------------------
Subject: -74- 1.2 libpf Phase toggling overlapped cull and draw
Date: 8 Apr 94 00:00:01 EST
When running in the PFMP_CULLoDRAW multiprocessing mode, changing the
phase from PFPHASE_LOCK or PFPHASE_FLOAT to PFPHASE_FREE_RUN or
PFPHASE_LIMIT can cause the application to deadlock.
In perfly, rapidly toggling the phase when running with the
PFMP_CULLoDRAW multiprocessing model ("perfly -m 65540" or "perfly -m
65542") can cause the application to hang.
Workaround: toggle only once every few frames or not at all.
------------------------------
Subject: -75- 1.2 libpf pfDataPool warning on exit
Date: 8 Apr 94 00:00:01 EST
A warning similar to the following sometimes occurs when a sample
program exits: "Performer Warning (2): pfReleaseDPool() Could not
unlink arena shared memory /usr/tmp/pfUtilDataPool11638.pfdpool."
This warning is harmless and can be ignored.
------------------------------
Subject: -76- 1.2 libpf Multi-channel stats warning messages
Date: 8 Apr 94 00:00:01 EST
When a multi-channel libpf application enables libpr pfStats modes
(such as graphics statistics -- PFSTATS_GFX) in multiple channels at
the same time, warning messages are printed every frame. The
calculated statistics will be correct. To stop the stream of warning
messages, raise the pfNotifyLevel in the program or set the
enviornment variable PFNFYLEVEL to a value smaller than 2.
------------------------------
Subject: -77- 1.2 libpf Video warnings on Indy when multiprocessed
Date: 8 Apr 94 00:00:01 EST
When an application on an Indy is forced to run the APP and DRAW in
separate processes, e.g. pfMultiprocess(PFMP_APP_CULLDRAW),
pfGetVideoRate warnings are printed when process timing stats are
on. To stop the stream of warning messages, raise the pfNotifyLevel
in the program or set the enviornment variable PFNFYLEVEL to a value
smaller than 2.
------------------------------
Subject: -78- 1.2 stats Frame statistics for lightpoints
Date: 8 Apr 94 00:00:01 EST
pfFrameStats for visible uni-directional and bi-directional
pfLightPoint nodes and points are incorrect. These statistics are
part of the pfFrameStats database statistics (PFFSTATS_DB) and these
specific counts are incorrect. However, the counts for total number
of visible pfLightPoint nodes and points are correct, and so are the
counts for Omni-directional pfLightPoint nodes and points. However,
these numbers are only counted when PFFSTATS_CULL are enabled.
------------------------------
Subject: -79- 1.2 stats Pixel fill statistics under 4.0.5 on
RealityEngine
Date: 8 Apr 94 00:00:01 EST
Under 4.0.5, fill statistics do not work when multisampling.
Workaround: turn off multisampling.
------------------------------
Subject: -80- 1.2 libpr Directional pfLightPoints
Date: 8 Apr 94 00:00:01 EST
Specifying a pfLightPoint node as PFLP_UNIDIRECTIONAL or
PFLP_BIDIRECTIONAL can cause a core dump in pfLightPoint::cull.
Workaround: set the color of the first light point with
pfLPointColor(lp, 0, color) before calling pfLPointShape.
------------------------------
Subject: -81- 1.2 libpfutil pfuCollide is jerky
Date: 8 Apr 94 00:00:01 EST
The collision model jerks and bounces when you keep hitting
something.
------------------------------
Subject: -82- 1.2 libpfutil pfuSaveImage broken
Date: 8 Apr 94 00:00:01 EST
The image file generated by pfuSaveImage is bogus.
------------------------------
Subject: -83- 1.2 libpfsgi pfLoadDxf loader is incomplete
Date: 8 Apr 94 00:00:01 EST
The DXF loader does not fully support the format.
------------------------------
Subject: -84- 1.2 libpfsgi pfLoadIv loader is incomplete
Date: 8 Apr 94 00:00:01 EST
The IRIS Inventor loader reads a subset of the IRIS Inventor 1.0
format.
------------------------------
Subject: -85- 1.2 GLX Overlay text with GLX on 4.0.5
Date: 8 Apr 94 00:00:01 EST
In the sample programs (e.g. perfly) on some platforms, sometimes
drawing messages (pfuDrawMessageCI) to the overlay planes in GLX mode
doesn't work under 4.0.5. Workaround: use only in GL mode (e.g. do
not use "perfly -x") or upgrade to IRIX 5.2.
------------------------------
Subject: -86- 1.2 GLX Toggling antialiasing with GLX on 4.0.5
RealityEngine
Date: 8 Apr 94 00:00:01 EST
Toggling antialiasing in the sample programs running in GLX mode on a
4.0.5 RealityEngine apparently confuses the graphics pipe and causes
wild texturing. Workaround: use only in GL mode (e.g. do not use
"perfly -x") or upgrade to IRIX 5.2.
------------------------------
Subject: -87- 1.2 GLX Toggling antialiasing with GLX on any
RealityEngine
Date: 8 Apr 94 00:00:01 EST
When antialiasing is toggled with the GUI in GLX mode, the GL window
changes. As each texture textures first comes into view, it is
downloaded to the graphics hardware. Occasional pauses will be seen
until all textures are reloaded in the graphics hardware. This can
be avoided by redownloading all textures (pfuDownloadTexList).
------------------------------
Subject: -88- 1.2 GLX on 4.0.5 Indigo, sample programs hang on
startup.
Date: 8 Apr 94 00:00:01 EST
Some sample programs will hang on startup if in GLX mode.
Workaround: start up only in GL mode (e.g. do not use "perfly -x")
or upgrade to IRIX 5.2.
------------------------------
Subject: -89- 1.2 samples smallfly drive models broken
Date: 8 Apr 94 00:00:01 EST
Toggling the drive-model button in smallfly can cause unexpected
results.
------------------------------
Subject: -90- 1.2 samples pickfly drops core under abuse
Date: 8 Apr 94 00:00:01 EST
When aggressively navigating the hierarchy, the number of pfSCSes in
the scene graph can exceed the maximum libpf traversal depth of 64.
------------------------------
Subject: -91- 1.2 samples detail example broken on 4.0.5
Date: 8 Apr 94 00:00:01 EST
The example program sample/pguide/libpf/progs/detail.c doesn't run
properly under 4.0.5. Workaround: upgrade to 5.2.
------------------------------
Subject: -92- 1.2 friends Belvis makefile requires pmake
Date: 8 Apr 94 00:00:01 EST
The makefile for the belvis demo in the Computer Arts and Development
section requires the pmake utility. Workaround: install
dev.sw.make.
------------------------------
Subject: -93- 1.2 friends Toon has bad models and textures
Date: 8 Apr 94 00:00:01 EST
Some of the textures are mixed up in toon town.
------------------------------
Subject: -94- 1.2 docs pfuGetGLXWin wrong on reference page
Date: 8 Apr 94 00:00:01 EST
The prototype in the man page should read: "extern void
pfuGetGLXWin(pfPipe *_pipe, pfuGLXWindow *_glxWin);" pfuGetGLXWin
copies the active GLX windows (normal and overlay) for the specified
pipe into the provided pfuGLXWindow structure. The active windows
change when a different GLX visual is requested.
------------------------------
Subject: -95- 1.2 docs pfuLockDownApp gives the incorrect location
Date: 8 Apr 94 00:00:01 EST
pfuLockDownApp gives the incorrect location for the procsetup.c
example: The correct location for this example is:
/usr/src/Performer/src/pguide/libpfutil/progs/procsetup.c
Additionally, the reference page should mention the example
/usr/src/Performer/src/pguide/libpf/progs/bench.c
------------------------------
Subject: -96- 1.1 Bug with FP underflow
Date: 26 Oct 93 00:00:01 EST
The cull process could encounter an FP underflow that could
periodically affect cull performance.
------------------------------
Subject: -97- 1.1 Bug with Multipipe Onyx
Date: 26 Oct 93 00:00:01 EST
There is a bug in the 1.1 multipipe code. The symptom is a core dump
and an error like:
Performer Fatal (4):pfFree() pointer 0x9c9350 not from pfMalloc
The workaround is to do the following after you've created a channel
with pfNewChan:
((long**)chan)[3] = NULL;
This workaround MUST NOT BE USED in Performer 1.2 applications.
------------------------------
Subject: -98- 1.1 Bug Installing on Indy or Indigo2 XL
Date: 8 Apr 94 00:00:01 EST
The problems are related to the way that Performer recognizes the
graphics hardware in the machine. Since the Indy was introduced
after Performer 1.1 released, Performer is unable to match the
graphics type (NEWPORT) with the hardware types it knows. This
effects both the installation and run-time applications.
/usr/lib/libpr.a, /usr/lib/libpr-g.a, /usr/src/Performer/demo/perfly,
and /usr/src/Performer/src/perfly/Makefile are machine-tagged in inst
as platform-specific and will not be installed by default.
WORKAROUND: You must remove IRIS Performer 1.1 from your machine and
re-install, explicitly defining the graphics hardware type. LIGHT
(Entry) graphics is the closest approximation to NEWPORT.
% su
# versions remove performer_eoe
# versions remove performer_dev
# inst -f <pathname> -m GFXBOARD=LIGHT
------------------------------
Subject: -99- 1.1 Bug Unable to determine Indy graphics type
Date: 8 Apr 94 00:00:01 EST
Performer 1.1 applications on Indy display the message: "unable to
determine graphics type -1. Default: VENICE"
WORKAROUND: The above message means that Performer was unable to
match NEWPORT graphics to a known graphics type, and has defaulted to
VENICE (RealityEngine). This could cause some anomalous behavior in
your application. There is no specific workaround at this time.
------------------------------
Subject: -100- 1.1 Bug perfly cannot find libpf.so on Indy running 5.1
Date: 8 Apr 94 00:00:01 EST
/usr/src/Performer/demo/perfly fails with the error message:
"perfly: rld: Fatal Error: cannot find soname 'libpf.so'"
WORKAROUND: You must recompile perfly from the source code provided
in /usr/src/Performer/src/perfly.
------------------------------
Subject: -101- 1.1 Bug perfly FP error messages in 5.0.1
Date: 8 Apr 94 00:00:01 EST
perfly prints the following error message(s) several times each
frame:
"Performer Info:FP division by zero"
"Performer Info:FP infinity minus infinity"
WORKAROUND: This is caused by a bug in IRIS GL and is not a fatal
error. Run perfly with the "-n 2" option to disable these (and any
other) informational messages.
------------------------------
Subject: -102- 1.1 Bug Installation on IRIX 5.2 - missing prerequisites
Date: 8 Apr 94 00:00:01 EST
When trying to install IRIS Performer 1.1 on a machine running IRIX
5.2, you will get an error regarding a missing prerequisite,
"dev.sw.libC". This subsystem contained the C++ runtime library. In
5.2 it has been renamed to "c++_eoe.sw.lib".
WORKAROUND: 'set rulesoverride on' from within inst.
------------------------------
Subject: -103- 1.0/1.1 Bug intersections with pfSwitch'es
Date: 26 Oct 93 00:00:01 EST
Intersections with pfSwitch'es whose value is PFSWITCH_OFF could
cause a core dump.
------------------------------
Subject: -104- 1.0/1.1 Bug with pfTexture()
Date: 26 Oct 93 00:00:01 EST
On RealityEngine systems, EXTERNAL format was ignored.
------------------------------
Subject: -105- 1.0/1.1 Bug with pfAntiAlias()
Date: 26 Oct 93 00:00:01 EST
On RealityEngine systems, pfAntialias(PFAA_OFF) did not turn off
multisampling.
------------------------------
Subject: -106- 1.0/1.1 Bug with pfFlatten()
Date: 26 Oct 93 00:00:01 EST
pfFlatten did not dirty bounding spheres of flattened nodes so they
had improper bounds and would not cull correctly.
------------------------------
Subject: -107- 1.0/1.1 Bug with pfSequences
Date: 26 Oct 93 00:00:01 EST
pfSequences: PFSEQ_RESUME ignored children's display times and drew
subsequent children for 1 frame only.
------------------------------
Subject: -108- 1.0/1.1 Bug with pfClosestPtOnPlane()
Date: 26 Oct 93 00:00:01 EST
pfClosestPtOnPlane returned wrong result. Also, the man page had the
wrong prototype.
------------------------------
Subject: -109- 1.0/1.1 Bug on ELAN/XS with wireframe PFGS_QUADS
Date: 26 Oct 93 00:00:01 EST
On EXPRESS Graphics platforms (XS, XS24, ELAN, etc), wireframe quads
have a stray line from one vertex to "infinity" when displayed in
wireframe mode.
------------------------------
Subject: -110- 1.0/1.2-IRIX4 Bug Z buffer configuration on 4.0.5
RealityEngine
Date: 8 Apr 94 00:00:01 EST
Z buffer config on 4.0.5 RealityEngine: On some versions of IRIX
4.0.5, mssize(4,24,1) (the default by pfAntiAlias) generates an
unusable Z configuration. For these machines, call mssize(4,32,1)
followed by gconfig() in your pipe initialization routine and do not
attempt to toggle antialiasing.
------------------------------
Subject: -111- 1.0 Bug pfInit(): mmap failed for /dev/zero
Date: 26 Oct 93 00:00:01 EST
This means that you tried to run a Performer 1.0 application (such
as a 4.x version of perfly) on a machine running IRIX 5.x. Virtual
memory management is different in IRIX 5.x. In order for your
program to work properly you must:
% setenv PFTMPDIR /usr/tmp
------------------------------
Subject: -112- 1.0 Doc Bug in pfMakePolarSeg() man page
Date: 26 Oct 93 00:00:01 EST
The man page for pfMakePolarSeg contradicts itself with respect to
the meaning of azimuth and elevation. The correct paragraph should
be:
pfMakePolarSeg sets dst to the segment which starts at pos and
has length length and points in the direction specified by azi
and elev. azi specifies the azimuth (or heading), which is the
angle which the projection of the segment in the X-Y plane
makes with the +Y axis. elev specifies the elevation (or
pitch), the angle with respect to the X-Y plane. The positive
Y axis is azi=0 and elev=0. Azimuth follows the right hand
rule about the +Z azis, e.g. - +90 degrees is the -X axis.
Similarly, elevation follows the right hand rule about the X
axis, e.g. - +90 degrees is the +Z axis.
Note that in IRIS Performer 1.0, an azi and elev of 0.0 is equivalent
to the +X axis while in 1.1, this has been changed to the +Y axis.
------------------------------
Subject: -113- 1.0 Doc Bug in pfDispList() man page
Date: 26 Oct 93 00:00:01 EST
The pfDispList man page says the size argument is in bytes; it should
say words.
------------------------------
Subject: -114- 1.0 Doc Bug in PFPG (simple.c)
Date: 26 Oct 93 00:00:01 EST
The program simple.c in the IRIS Performer Programming Guide (PFPG)
does not bind a light and draws a black image on Elan systems. The
corrected version, which creates and binds a light in the pipe
initialization callback, is in /usr/src/Performer/src/pguide
------------------------------
Subject: -115- 1.0 Bug in pfGetTime()
Date: 26 Oct 93 00:00:01 EST
In 1.0, pfGetTime() would occasionally return bad values (off by
4000+ seconds) on Indigo2 and machines without a fast counter, e.g.
PowerSeries/IO2.
There was no workaround.
------------------------------
Subject: -116- 1.0 Bug in pfNodeBBox()
Date: 26 Oct 93 00:00:01 EST
pfNodeBBox did not set the bounding box of a node. A symptom was
that the bounding boxes of the node would not change when modifying a
parent pfDCS.
The workaround was to OR the value 0x0010 into the mode, e.g.-
pfNodeBBox(node, &bbox, PFN_BMODE_STATIC | 0x0010);
------------------------------
Subject: -117- 1.0 Bug in pfInitGfx() with Z-buffer on RealityEngine
Date: 26 Oct 93 00:00:01 EST
pfInitGfx on RealityEngines would call lsetdepth(0x0, 0x0),
essentially disabling zbuffering.
The workaround was to call lsetdepth explicitly after pfInitGfx, in
the pipe initialization callback.
------------------------------
Subject: -118- 1.0 Bug in libpfflt combineLODs()
Date: 26 Oct 93 00:00:01 EST
combineLODs() in the MultiGen .flt converter (in file hier.c) did not
set the LOD center of combined LODs. This would result in strange
LOD behavior for LODs which were not modelled about the origin.
(The current OpenFlight loader, revision R14_2, correctly uses the
center when combining LODs and can combine any number of sibling
LOD's for improved efficiency.)
------------------------------
Subject: -119- 1.0 Bug with two-sided material and pfMtlColorMode()
Date: 26 Oct 93 00:00:01 EST
Applying a back-sided material which had a color mode
(pfMtlColorMode), would set the GL lmcolor mode. Since IrisGL does
not support lmcolor for back-sided materials, this could have caused
front-sided materials to use an improper lmcolor mode.
------------------------------
Subject: -120- 1.0 Bug in pfFilePath()
Date: 26 Oct 93 00:00:01 EST
pfFilePath would exit with a FATAL error if it was called twice.
------------------------------
Subject: -121- 1.0 Bug in pfGetCurGState()
Date: 26 Oct 93 00:00:01 EST
pfGetCurGState returned a pfGeoState which was the top of the state
stack rather than the most recently applied pfGeoState.
------------------------------
Subject: -122- 1.0 Bug in pfGetCurState()
Date: 26 Oct 93 00:00:01 EST
pfGetCurState returned a pfGeoState which was the top of the state
stack rather than the current pfState.
------------------------------
Subject: -123- 1.0 Bug with cloned scenes
Date: 26 Oct 93 00:00:01 EST
pfClone()'ed scenes were not properly cleaned and did not properly
propagate updates. In particular, cloned pfSequences did not work.
------------------------------
Subject: -124- 1.0 Bug intersections in collide.c
Date: 26 Oct 93 00:00:01 EST
collide.c was shipped with a hardwired intersection mode which turned
off intersection caching, substantially reducing intersection
performance.
------------------------------
Subject: -125- 1.0 Bug with flattened pfLightPoints
Date: 26 Oct 93 00:00:01 EST
pfFlatten()'ed pfLightPoints were broken for multiprocessing modes
when the application and cull processes were separate.
------------------------------
Subject: -126- 1.0 Bug intersections with pfSequences
Date: 26 Oct 93 00:00:01 EST
Intersections with pfSequences could sometimes turn them off
(PFSEQ_STOP).
------------------------------
Subject: -127- 1.0 Bug intersections with non-indexed quads
Date: 26 Oct 93 00:00:01 EST
Intersection caching for non-indexed quads was broken and could case
a core dump when intersection with pfGeoSets of this type.
------------------------------
End of sgi/faq/performer Digest
******************************
--
The SGI FAQ group <sgi-faq@viz.tamu.edu> http://www-viz.tamu.edu/~sgi-faq/
Finger us for info on the SGI FAQs, or look in ftp://viz.tamu.edu/pub/sgi/.
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |