Hi All, A month of so back I developed a new expiry scheme for DatabasePager that works to ensure that number of PagedLOD in memory at any one time does not exceed a specified target maximum number of PagedLOD. The new scheme allows the number of PagedLOD in memory to raise until it hits the target maximum number of PagedLOD, and then if any new PagedLOD's are request non visible PagedLOD's are then expired to balance the total number in memory.
The new scheme contrasted the previous scheme of expiry delay and expiry frames as these only expiry non visible PagedLOD subgraphs if they hadn't be viewed for a maximum number of seconds or frames, neither of these schemes could directly limit the total resources used, and if you moved the eye point quickly it was possible to reach quite high numbers of PagedLOD in memory as new subgraphs in wouldn't be balanced by expiry of non visible ones. The new scheme offers far better control on how memory your application will require, so should be able to cope better with a wide range of usage models and machines. Another advantage of the new scheme is that if you do have sufficient memory you can allow the target maximum to go up and then you can keep lots of data in memory so that if you are moving around the terrain quickly from place to place and then returning you'll not have to wait for data to paged in as it'll already be in memory. A further advantage it that it isn't isn't either time or frame based you don't need to select a scheme the works best for frame driven or event driven apps, one setting works just the same for both types of applications. -- The other change I've made, and this one it potentially more contentious is that I've disable the pre compile feature of the DatabasePager by default. The pre compile feature is used to limit the number of OpenGL objects that are compiled/deleted per frame, this feature is meant to reduce the liklihood of frame drops due a new subgraph being merged that has so much OpenGL data to compile that introducing it causes a frame drop. The down side of pre-compile is that it increases the latency between when a tile is first requested and when it's finally merged. With my own testing on databases I rare see frame drops with not havin pre-compile enabled, but do notice the extra latency especially when moving to new regions rapidly so only balance I've made the call that we'll better visual quality from out databases with pre compile disabled. Now I say it's contentious as making this change may make your applications more prone to frame drops, and if this is critical for you then this change is not ideal. It's also only mean own testing across the machines I have to suggests to me that frame drop issue is not as critical as it once was - the pre compile used to essential to avoid frame drops when I first wrote the DatabasePager back in the early days of the OSG. On you own machines/OS's things may be different, the pre compile may still be the best default for you. It is only the defaults I've changed so you still enable pre compile either via the OSG_DO_PRECOMPILE env var or DatabasePager::setDoPreCompile(true). -- With these two changes my hope is that DatabasePager will now work better out of the box for more OSG users that the previous settings. Whether it achieves this or not is something I can say, I need feedback from the community on how well the new defaults pan out in end users applications or their machines with their databases. So please check out svn/trunk or the next dev release (2.7.8 due in a couple of days) and let me know. Thanks, Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
