Thanks a lot Robert. I understand why caching is necessary, it just seemed redundant to make both the plugin and the Registry responsible for adding archives to the cache.
The archive count is a condition passed down from a higher processing step, which we don't really have much control over. As a result, we just need to make it work. My first guess for the access violation is that windows is imposing a limit on the amount of global space an application can use. That's a long shot guess though. I'd assume that even though the map's handle is on the global stack, its members would still be on the heap. Chase -----Original Message----- From: [EMAIL PROTECTED] on behalf of Robert Osfield Sent: Thu 5/10/2007 1:15 AM To: osg users Subject: Re: [osg-users] OSGA Plugin ignores CACHE_NONE option Hi Brad, I have reviewed the code and added a options check into the .osga plugin. Could you do a svn update and see how you get on. W.r.t an archive adding itself to the cache, this is done so that future read calls can reference the cache without having to re-load it. The archive should be reasonably lightweight - its basically just a file index that you load, the actual models themselves are loaded on demand. Loading a compiling the index does take a little bit of time, so you don't want to keep loading the archive just to access one file from it. I'm suprised by two things, one that you have more than 508 archives in the first place, the idea of archives is that pack lots of files into a single archive so have small working set of archives at any one time, second that loading this many archives blows memory, it'd be interesting tracking down how much each loaded archive is taking, perhaps its being a bit inefficient somewhere along the line. Robert. On 5/9/07, Bradford, Chase <[EMAIL PROTECTED]> wrote: > > Hey Everyone, > > > > I've been working with some data that uses many osga files that hold > PagedLODs, and I've found that if we ever exceed 508 osga files, subsequent > calls to openArchive or readNodeFile fails. After some debugging, I've > zeroed in on some issue where too many entries in the > osgDB::Registry::archiveCache is causing Windows to generate a memory access > error. I started setting the osgDB::Registry::Options objectCacheHint to > CACHE_NONE, but the archive cache kept getting populated. It turns out that > the osga plugin's readImage and readNode call addToArchiveCache directly > regardless of the options used. When I comment out those line in the plugin > code and use CACHE_NONE I can load all of my data with no issue. > > > > It seems like when caching is enabled, that call is redundant. Should the > OSGA plugin really add itself to the cache? > > > > Thanks, > > Chase > > _______________________________________________ > osg-users mailing list > [email protected] > http://openscenegraph.net/mailman/listinfo/osg-users > http://www.openscenegraph.org/ >
<<winmail.dat>>
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
