From: Brian Furtaw (brian++at++sgi.com)
Date: 09/03/2003 02:44:34
Performer doesn't delete well and you should not delete OpenGL resources
anyway it takes far too long to accomplish. You are better off creating
a set of proxy textures ahead of time and subloading the texture data
separately from the terrain data. Performer can help you in this case it
has a sharing facility pfuMakeTexList and the pfuTextureManager.
You are better off subloading the terrain data also. Performer has dted
and dem loaders use them and a pfFlux to buffer the incoming terrain
height information, try looking at
/usr/share/Performer/src/pguide/libpf/C++/fluxed_gset.C.
Use pfAsyncDelete to take care of models you are loading and unloading.
You will still need to manage the amount of data you are deleteing. But
that task is much easier when you are just dealing with models. Again
look at using pfdShare and pfuMakeTexList to share graphics state and
texture between models. The pfdBuilder which isuesd by the Performer
loaders will already try to take advantage of the facilities in pfdShare
to give you efficient graphics state usage.
Brian
Andreas.Lenz++at++esg.de wrote:
> Hi folks,
>
> I'm still working on a terrain visualisation for a flight simulation, which
> uses a paging
> process to load terrain tiles dynamically into the scene. Typically there
> are 9 (+-3)
> tiles paged at the same time. Tiles are loaded as .pfb files, which are
> each about
> 3MB large - textures not included. As an average 3 tiles are loaded and
> should be
> deleted avery 30 seconds.
> When i try to delete tiles in my database function, the call to pfDBase
> takes very much
> time - especially when i try to delete more tiles at the same time. Delays
> may last for a
> minute or more.
> I tried to remove the tile-nodes from the scene without deleting them and
> there were no
> delays, of course until the memory of the shared arena was used. But it
> showed that
> loading of the tiles was not the problem, just the deletion.
>
> The application is build on the perfly source code.
> I programmed the database function following the example in the pfBuffer
> man pages
> using the C++ API, which looks basically like:
>
> pfNode **Tiles; //allocated in main()
>
> void myDBaseFunc (void)
> {
> bool changed = false;
>
> static pfBuffer *Buffer = NULL;
> if (Buffer == NULL)
> Buffer = new pfBuffer;
>
> Buffer->select();
>
> if (Tiles[index] should be paged)
> {
> Tiles[index] = pfdLoadFile(file); // which is a .pfb
> Shared->scene->bufferAddChild ( Tiles[index] );
> changed = true;
> }
>
> if (Tiles[index] should be removed)
> {
> Shared->scene->bufferRemoveChild( Tiles[index] );
> pfAsyncDelete( Tiles[index] );
> changed = true;
> }
>
> if( changed )
> Buffer->merge();
>
> pfDBase();
> }
>
> I wonder what might cause the long delay in the call to pfDBase().
> What I'm not sure about is, if a delete the tiles correctly. Especially
> I'm not sure what happens to textures. As far as i understand textures
> are loaded whith the above call Tiles[index] = pfdLoadFile("myTile.pfb").
> Of course several tiles use the same textures. Are the textures shared
> and what happens to them if i try to delete a tile ? Do i have to delete
> the textures explicit ?
> Would it be possible to put all the textures i might use in a .flt file
> which i could load at program start ?
>
> Any help on the correct way of deleting unused tiles (and textures) is
> welcome. Is there any sample code, which handles this problem ?
>
> I also thought about, that the problem might be related to the hardware.
> I'm running the application on a Dual-Xeon (2x2 GHz) with activated
> hyper-threading, SUSE-Linux 8.2, smp-kernel 2.4.20, GeForce4 Ti4600 with
> latest NVIDIA drivers, XFree 4.3.
> I tried perfomer versions 2.5 and 3.0.2 with no difference.
>
> Thanks for your help,
>
> Andreas Lenz
>
> ------------------------------------------------------------
> Andreas Lenz ESG GmbH
> Einsteinstrasse 174 D-81675 München
> Tel.: ++49-89-9216-2167
> Fax.: ++49-89-9216-2632
> Mail: Andreas.Lenz++at++esg.de
> ------------------------------------------------------------
>
>
>
>
> -----------------------------------------------------------------------
> 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
> -----------------------------------------------------------------------
--
----oOOo---- ----oOOo---- ----oOOo---- ----oOOo----
Brian Furtaw (brian++at++sgi.com) Mailstop: DSE-2612
Graphics Guru Office:(301)814.6858 Fax: (253)323-8182
12200-G Plum Orchard Drive OpenGL/OpenGL Performer/Commodity Graphics
Silver Spring, Maryland 20904 Solutions and Integration Services
This archive was generated by hypermail 2b29 : Wed Sep 03 2003 - 02:53:19 PDT