Re: Multigen load is real slow...

New Message Reply Date view Thread view Subject view Author view

Richard McDonald (richard++at++gossamar.paradigmsim.com)
Mon, 18 Nov 1996 18:58:51 -0600


On Nov 15, 3:27pm, Russell Suter wrote:
> Subject: Re: Multigen load is real slow...
> On Nov 15, 3:54pm, Richard McDonald wrote:
> > Subject: Re: Multigen load is real slow...
> > On Nov 15, 1:36pm, Russell Suter wrote:
> > > Subject: Multigen load is real slow...
> > > Hey again,
> > >
> > > I have a Multigen database that took a little less than a minute to load
> > > with pf1.2 and Irix 5.3. Since going to the IR with pf2.1 and Irix 6.2,
> > > the load takes about 2.5 hours. Yes, that's hours. What happened. I'm
> > > guessing that its not using physical memory but starting to do virtual
> > > paging a little too early. The problem occures in my application as well
> > > as perfly. The first part of the load is real fast but it reaches a
point
> > > and just crawls. Is there some parameter I can set so that RAM is
> prefered?
> >
> > Considering that you are running on a 1st class machine with smarter
> software,
> > more memory, lots of RMs, and other good stuff, your problem may not be
> > memory paging (if you suspect this, you can run grosview while loading to
> > watch the page hits). You may be running across a situation which we
> > encountered before.
> >
> > Do you see any warning messages from the loader? You should be using a
> > pfNotifyLevel of at least PFNFY_WARN to see these. If so, are these in
> > reference to missing textures or application of detail textures?
> > We have found that when the loader has to resolve texture descrepencies,
> > the load times go up dramatically; usually by an order of magnitude!
> > However, if the problems are corrected in the multigen file(s), the load
> > times are usually quite reasonable. I suspect this is because the loader
> > is doing a more comprehensive job wrt texture.
>
> 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. 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. When you said
> "if the problems are corrected in the multigenfiles..." are you suggesting
> that I do something to my database to fix this? I'm not well versed in
> Multigen but if you hum a few bars...

The short answer is yes, you will need to fix the database. What you are
likely experiencing is problems with usage of detail textures. The first
reference to a detail texture from a polygon which contains a texture and
a detail texture, establishes a unique 1-to-1 relationship of base texture
to detail. This unique pairing may not be used in any other way from there
on. For example, if you have a polygon which uses "foo" as its base texture
and "bar" as its detail texture... any and all other polygons which use
"foo" MUST have an identified detail texture and it MUST be "bar"; otherwise,
the loader first warns you about the problem and then proceeds to try and fix
it. The fix is what is probably consuming most of the load time.
(Previous versions of the loader punted in this situation, and what you got
was usually a bizarrly textured database). Likewise, no other polygon may
ever use "bar" as a base texture. If "bar" is desired as a base texture
elsewhere, you will need to make a copy of it with a different name.

Rather than eliminating the ".attr" files, its probably better to correct
both these and your database. You can do this from within Multigen by editing
the textures as necessary, bearing in mind the unique relationship.

The only way I know of to correct the pairing within the file(s) is to open
each one individually (can't go through an external) with multigen, select the
polygon icon; select all polygons whose base texture matches the base texture
(review your manuals for any details); select "global Attribute Modify";
bring up the property sheet withthe "=" key; type in the id number for the
correct detail texture; "zap" the property sheet; write out the file.

Next, repeat the procedure for any textures which might use the detail
id as a base texture, and replace it with a unique copy.

Be sure and study the loader's warnings with care as similar to a compiler,
most of the real problems are printed out at the beginning.

> >
> > >
> > > Any info would be greatly appreciated. And appologies if this topic has
> > > been discussed.
> >
> >
> >
> > --
> > --
> >
> > Richard McDonald
> > ___________________________________________________________
> >
> > richard++at++paradigmsim.com Paradigm Simulation, Inc.
> > voice: (972) 960-2301 14900 Landmark Blvd Ste 400
> > fax: (972) 960-2303 Dallas, TX 75240-6725
> > ___________________________________________________________
> >-- End of excerpt from Richard McDonald
>
>
> Once again, any help is appreciated. And thank you Richard for your most
> helpful and insightful response!
>
> --
> 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
> ________________________________________________|______________________________
>-- End of excerpt from Russell Suter

Hope this was helpful,

-- 
--

Richard McDonald ___________________________________________________________

richard++at++paradigmsim.com Paradigm Simulation, Inc. voice: (972) 960-2301 14900 Landmark Blvd Ste 400 fax: (972) 960-2303 Dallas, TX 75240-6725 ___________________________________________________________ ======================================================================= 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.