Hi Allen,
Allen Bierbaum wrote:
> Hello all:
>
> I am going through and optimizing one of our applications, and I have
> found something a bit interesting. In some of our scenes, we have
> thousands of models that could be displayed and each of them have very
> high resolution textures. To help with this, we are using a large
> number of screen size LODs in an attempt to reduce the graphics
> resources needed at any one time.
>
> What surprised me though (although it probably shouldn't have) is that
> once a texture or display lists (or VBOS/FBOs) are allocated for a
> geometry and material, they remain allocated even though they may be in
> a sub-tree of the LOD node that is not currently active. This leads to
> the unfortunate side-effect that we run through 1.5 GB of texture memory
> (and system memory) *very* quickly when flying over the models in our
> scene because each one loads the highest resolution texture at some
> point and leaves it loaded in the system.
Hm, yup, that's a problem.
> So, what I propose doing is modifying the screen size lod to include a
> flag that tells the system to unload all graphics resources when a
> sub-branch is deactivated. Unfortunately, I don't know how to do this.
>
> Can anyone point me in the right direction?
I don't think there is a real way to do that right now. :-/
The things that really up up gfx memory are Geometry Dlists/VBOs and textures.
In OpenSG all of those are GLObjects and handled in the Window, and identified
by their ID. To destroy them you the IDs, so you need to traverse the tree and
pick up all TextureChunks and Geometries. The Geometries are fairly easy, the
TCs can be a little hidden (all Materials, MaterialGroups, MultiMaterials
etc.).
Access to the ID is the first problem, as they are private. It would probably
be
the cleanest solution to add an unload() method to the Geometry and TCs (maybe
Materials?) to initiate the resource freeing.
Assuming you have the ID the Window only has a method to fully destroy the
object (destroyGLObject), which primarily adds it to the _glObjectDestroyList.
This list is traversed in frameExit and the destroy methods in the FCs are
called (handleDestroyGL), which do the actual OpenGL calls, and the object is
removed from the internal structures. To do what you need to do those would
have
to be separate, and the frameExit code needs to know whether an object needs to
just be cleared or actually removed. If the latter it should be kept in the
lists and just set to not initialized.
The basics of that should be fairly easy to add, but the object handling code
has a lot of special cases (what about objects that are initialized and
destroyed in the same frame? Or objects that are cleared and destroyed in teh
same frame? etc. etc.), so making it work in all cases can get tricky.
Hope it helps
Dirk
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
