Stuart Levy (slevy++at++ncsa.uiuc.edu)
Fri, 1 May 1998 11:14:35 -0500 (CDT)
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++at++ncsa.uiuc.edu
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:57:21 PDT