From: Gordon Tomlinson (Gordon.Tomlinson++at++warhammeronline.com)
Date: 11/14/2003 02:57:16
Hi
YES This WAS bug a in the OpenFlight loader and it was fixed in a later release, sorry I cannot remember which one it was I thing 15.7 or so .
You might have a problem getting an updated loader from MPI, as they drop direct support of the OpenFlight loader for Performer along while ago and don't support Performer on Linux or Windows
Also you would need an active maintenance contract to get an updated loader.
Good luck
Gordon
( a big mistake by MPI's IMHO to drop Performer support for OpenFlight and not provide support to SGI on this in any real from, sort shoots themselves in the foot really)
-----Original Message-----
From: Tijs Zwinkels [mailto:openperformer++at++tumblecow.net]
Sent: 14 November 2003 09:47
To: info-performer++at++sgi.com
Cc: Paolo Farinelli; Michael.Petrou++at++sydac.com.au
Subject: Re: [info-performer] .flt Loader Problem.
Hello,
Thank you for your responses.
Unfortunately, calling pfdConverterMode as you described, didn't solve the
problem. I've send a bugreport to Multigen, perhaps they can shed some
light
on this issue.
I investigated the issue some further.
It turns out that not only a '1' is added after te nodename, but sometimes
other characters as well.
Very often a linefeed appears out of nowhere, and sometimes even other
chracters, as in this example:
Original Name: Name in performer tree on Linux:
mouseover_cruise mouseover_cruise\n
track_beam_SW_00 track_beam_SW_00\n
Building Building 1uH\n
The flight-files have been created on a Silicon Graphics O2 with
MultiGen (5.3 ?), which may be rather old.
Michael Petrou: Can i ask you which software /version / platform you used
to create the .flt files?
Any more people with this issue?
Greetings
Tijs Zwinkels
Paolo Farinelli said:
> Hi Tijs,
>
> you can try calling pfdConverterMode( "flt", PFFLT_USELONGIDS, 1);
>
> From the pfdConverterMode_flt man page:
>
> PFFLT_USELONGIDS
> When mode is set to TRUE (the default), the loader uses
> each OpenFlight bead's long ID to name the
> corresponding pfNode. When mode is FALSE, the loader
> uses each bead's short ID to name them instead.
>
>
> Hope this helps.
> Regards,
> Paolo
>
>
>
> Tijs Zwinkels wrote:
>
>>Performers,
>>
>>
>>I'm facing the following problem:
>>
>>Currently I'm porting a medium-sized application (approximately. 80.000
>>source lines) from the Onyx2 to Linux.
>>The models are stored in .flt files, but it seems that switches from
>> these
>>.flt files sometimes get a different name in the performer tree on Linux,
>>than on the Onyx.
>>
>>a example:
>>on Linux one of the switches is named: 'all_AD_SW_001'
>>but on the Onyx, the same switch is named 'all_AD_SW_00'
>>
>>If i grep in the models-directory, 'all_AD_SW_00' can be found, while
>>'all_AD_SW_001' can't.
>>
>>I'm suspecting the .flt loader.
>>Does anyone have any idea what can be wrong here?
>>
>>on Linux I'm using OpenGL Performer 3.0 rev. B, which comes with
>>OpenFlight (r) loader R15.4i.
>>On irix, Iris Performer Beta 2.2 with Openflight loader R15.4fi is used.
>>
>>Thanks in Advance,
>>Tijs Zwinkels
>>
>>-----------------------------------------------------------------------
>> List Archives, Info, FAQ: http://www.sgi.com/software/performer/
>> Open Development Project: http://oss.sgi.com/projects/performer/
>> Submissions: info-performer++at++sgi.com
>> Admin. requests: info-performer-request++at++sgi.com
>>-----------------------------------------------------------------------
>>
>>
>>
>>
>
>
> --
> Paolo Farinelli paolo++at++sgi.com
> Member of Technical Staff, OpenGL Performer 1-650-933-1808
> Silicon Graphics 1600 Amphitheatre Pkwy, Mountain View, CA 94043
>
>
>
-----------------------------------------------------------------------
List Archives, Info, FAQ: http://www.sgi.com/software/performer/
Open Development Project: http://oss.sgi.com/projects/performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
-----------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Fri Nov 14 2003 - 03:03:55 PST