Re: Multigen load is real slow...

New Message Reply Date view Thread view Subject view Author view

Marcus Barnes (marcus++at++multigen.com)
Fri, 15 Nov 1996 15:35:04 -0800


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.

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

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

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

Regards.

--
+ Marcus Barnes, Technical Staff        mailto:marcus++at++multigen.com +
+ Multigen Inc.                         http://www.multigen.com    +
+ 550 S. Winchester Blvd.               phoneto:1-408-556-2654     +
+ Suite 500 San Jose CA 95128           faxto:1-408-261-4102       +

attached mail follows:


From: "Marcus Barnes"
Date: Thu, 17 Oct 1996 11:37:26 -0700
To: info-performer++at++sgi.com
Subject: Re: Port problems from 1.2 to 2.0 IRIX gl an MultiGen
[munch]

> 2) I've got several MultiGen databases. When I try to load them with my > application (or perfly for that matter) I get the following output:

The 2.0 based OpenFlight loaders do extensive validity checking of texture usage. This is because of semantic changes between IRISGL and OpenGL texuring. Usages that were okay before may not be anymore. It also tests the Performer api a bit more too.

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

> PF Notice/Assert: polygon p16 missing detail texture index, but > is using base texture with detail filter. > PF base texture: > ../../visual/texture/aerial_6.rgb > PF bound detail: (null)

This is a notice from the OpenFlight loader. It means exactly what is says. Polygon "p16" doesn't have a detail texture index. The texture it's using has a detail mag. filter setting. There is no detail texture bound to it however.

> PF Warning/Usage(11): pfMemory::new() Unable to allocate 26640 bytes > from the heap. > Segmentation fault

You ran out of heap space. This may be true or more likely you are running on IRIX 6.2 which has a shared memory arena placement bug. This can cause the arena to be placed to near the heap, preventing reasonble heap growth.

> Thousands of those Notice/Assert messages pass by. All of the databases > fly fine in the perfly that came with Performer 1.2. > > So, what am I missing here??

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

Regards.

--
   __  ___     ____  _ _____        Marcus Barnes, marcus++at++multigen.com
  /  |/  /_ __/ / /_(_) ___/__ ___  Technical Staff, MultiGen Inc.
 / /|_/ / // / / __/ / (_ / -_) _ \ http://www.multigen.com
/_/  /_/\_,_/_/\__/_/\___/\__/_//_/ PH:1-408-556-2654 FX:1-408-261-4102
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer++at++sgi.com
        Admin. requests:  info-performer-request++at++sgi.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:57 PDT

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