HI Maciej, Thanks for the explanation about your data. I wouldn't have though that the scheme you use for generating the database would have any effect, perhaps it just highlights the problem better.
The new expiry scheme was working far better than the old schemes in terms of capping the overall memory consumption, so something has gone amiss as the debug info I'm getting back shows that database expiry isn't happening when I'd expect it too. Fingers crossed I'll be able to spot the problem quickly. Robert. On Wed, Dec 17, 2008 at 8:52 PM, Maciej Krol <[email protected]> wrote: > Hi Robert, > > We have custom paged database for high speed train simulator. PageLODs are > centered along the railroad. PagedLODs from L0 have radius 2km, L1 - 1km, L2 > - 0.5km. Above L0 there are few levels of Groups for fast culling. We do > not load pages from files but from custom pseudo loader that generates > geometry at runtime from internal track model. Graph layout is similar to > VPB but in one dimension, generated tiles contain Group of two PagedLODs, > each PagedLOD have two children (low and high level). The biggest difference > from VPB is that in L0 low level child does not contain geometry (it is > runtime generated), there is a reference to pseudo loader tile instead, just > like for high level. > > Our test scene is a 120 km long track containing about 60+120+240=420 > PagedLODs. Terrain database is not enabled. In tests train runs at 500km/h, > every 3.6 seconds new L2 tile is requested. > > Fix did not help at all besides debugger problems. Following memory usage is > reported. > OSG_MAX_PAGEDLOD=0 max 80MB > OSG_MAX_PAGEDLOD>0 400MB and increasing > > I know that pager "used" to work. It is the "killer" feature of OSG. I am > constantly keeping an eye on this issue, eagerly awaiting Your new ideas. > > Regards, > Maciej > > 2008/12/17 Robert Osfield <[email protected]> >> >> Hi Maciej, >> >> I've just upped the notify messages in >> DatabasePager::capped_removeExpiredSubgraphs(..) and found out that it >> is pruning, but not quite in the way it should be, allowing number of >> PagedLOD to raise too far. It *used* to work, so I'm not sure what >> has gone amiss... >> >> I'll will need to investigate this tomrrow as it's getting late here. >> In the meantime you'll need to set OSG_MAX_PAGEDLOD to 0 to get the >> old behaviour back. >> >> Robert. >> >> On Wed, Dec 17, 2008 at 7:36 PM, Robert Osfield >> <[email protected]> wrote: >> > HI Maciej, >> > >> > On Wed, Dec 17, 2008 at 7:09 PM, Maciej Krol <[email protected]> wrote: >> >> Now it makes sense, frankly I did not understand why You are trying do >> >> erase >> >> items from activePagedLODList rather than pagedLODList. It was beyond >> >> me, so >> >> just fixed bug locally. >> >> >> >> No crash in debug mode. Currently I am testing Your new pager with our >> >> paged >> >> databases. In old pager memory usage was contant about 80-100MB >> >> depending on >> >> scene complexity. In the new pager memory usage is contantly increasing >> >> reaching 500MB after 15 minutes of scene roaming. Setting >> >> OSG_MAX_PAGEDLOD >> >> to low value (i.e. 30) does not help. There no notify messages about >> >> releasing pages either. >> > >> > Is this growing memory consumption happening even with the fix? >> > >> > I don't see this issue with the databases I've tested so far. How was >> > this database built? >> > >> > Robert. >> > >> _______________________________________________ >> osg-submissions mailing list >> [email protected] >> >> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
