Re: Multigen load is real slow...

New Message Reply Date view Thread view Subject view Author view

Russell Suter (russell++at++ctasim.com)
Mon, 18 Nov 1996 14:36:32 -0700

On Nov 15, 3:35pm, Marcus Barnes wrote:
> Subject: Re: Multigen load is real slow...
>
> On Nov 15, 3:27pm, Russell Suter wrote:
> > On Nov 15, 3:54pm, Richard McDonald wrote:
> > > Do you see any warning messages from the loader? You should be using a
> > > pfNotifyLevel of at least PFNFY_WARN to see these.
>
> Newer OpenFlight loaders validate all detail texture usage. The messages are
> at PFNFY_NOTICE for the basic usage errors and PFNFY_DEBUG for the
potentially
> innocuous problems (like when a texture file cannot be read for some
transient
> reason).
>
> If your database has lots of pathological texture usage, that is no longer
> valid in OpenGL, then all the pfNotify() messages will certainly slow down
the
> load process. You can simply change you notify level to PFNFY_FATAL to
silence
> then and regard most of the load time. However the warnings are generally
> serious in that you will see texture anomolies. You should fix the database
as
> soon as you can.
>
> > > If so, are these in
> > > reference to missing textures or application of detail textures?
>
> If you mean "referencing missing palette member" notices then you are
misusing
> external reference texture palette override flags. You should not inherit
the
> parent file's texture palette unless it contains the same textures (by index)
> as referenced by the child file.
>
> > > We have found that when the loader has to resolve texture descrepencies,
> > > the load times go up dramatically; usually by an order of magnitude!
>
> True. The validation isn't that time consuming though. It is always being
> done. But when pfNotify() is called alot, you become I/O limited wrt shell
> output and scrolling.

After removing my .attr files, I don't get very many messages anymore but
the load is still slow.

>
> > Indeed, I do, or at least I did see a lot of detail texture warning
messages.
> > I had posted a message about it and got no response.
>
> Oh? I did respond to you in October ... see attached.

Sorry, didn't get it. But, after reading it, I wish I had gotten it. It
would have helped immensely.

>
> > I sent an email off to
> > support++at++multigen.com and they recommended that I remove my .attr files
> > associated with the texture files to get rid of the messages.
> > I did that
> > and now I don't get the warnings but in light of what you said, I assume
> > that removing the .attr files didn't really fix anything.
>
> This means that your texture ".attr" files are not "in sync" with your
database
> anymore. For example, your database has polygons that do no have detail
> texture, but their base texture's attribute file has a MOD_DETAIL mag.
filter.
> By simply removing the .attr files, you are letting the polygons "drive" the
> "default" texture attributes. In a sense ... it does fix the problem this
> mismatching attributes problem, by eliminating the texture attribute files.
>

But nothing has changed with the database for years. The only things different
are the IR, Irix 6.2 and Performer 2.1. In fact, I can run the old Irix 5.2/
Performer 1.2 version on the IR with 6.2 and Performer 2.1 loaded and the
database loads as it always did. It is only when I run the Irix 6.2/Performer
2.1 version that I have problems. I run the old one, no problem. I run the
new one on the exact same machine, time for a long nap.

> > When you said
> > "if the problems are corrected in the multigenfiles..." are you suggesting
> > that I do something to my database to fix this?
>
> Well if you have polygons that are supposed to have detail texture and they
are
> missing a detail texture index, or the base texture attribute file does not
> specify a DETAIL mag. filter ... then yes you want to correct the mismatches.

Would the old flt loader that came with Performer 1.2 have a problem with this?

[snip]

> > PF Info/Usage: IRIS GL spline specification is obsolete -
use
> > OpenGL style
>
> This is a message from pfTexSpline(). Your control points are IRISGL style
and
> it would like you to use OpenGL style.

Are you saying that Multigen is GL specific!?! Is this something changed in
V14.2?

> It could be the result of several factors. You're databases might have
always
> had these inconsitancies. You are using textures whose attributes have
changed
> over time. You have upgraded some .flt files to V14.2 from older version and
> your external reference override flags are not set right (see loader mode
> PFFLT_OLD_STYLE_XREFS).

If the flt loader didn't report these consistencies, I would bet that we always
had them. What does PFFLT_OLD_STYLE_XREFS do? Is this some kind of backwards
compatability mode?

Thanks Marcus.

-- 
Russ
________________________________________________ ______________________________
Though my eyes could see                        | Russell Suter
         I still was a blind man.               |    Voice : (303) 889-1262
                Though my mind could think      |      Fax : (303) 889-1210
                        I still was a mad man.  | Internet : russell++at++ctasim.com
________________________________________________|______________________________
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer++at++sgi.com
        Admin. requests:  info-performer-request++at++sgi.com

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:53:58 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.