Critical issue with paging and horizon!

classic Classic list List threaded Threaded
3 messages Options
Ben Discoe Ben Discoe
Reply | Threaded
Open this post in threaded view
|

Critical issue with paging and horizon!

My users have discovered a critical issue with how osgEarth, or more likely OSG's paging, deal with tiles that are out of the frustum.

It's easily to reproduce the problem: Load any imagelayer with plenty of depth (e.g. OSM), move close to the earth, look straight down at the ground, then rotate up swiftly to look at the horizon.  You can do it repeatedly, look down, look at horizon, back and forth.  Every time you look towards the horizon, there is a very serious dip in framerate (from 60fps down to <5fps for 1 or more seconds), presumably as all the texture tiles (to the horizon) come into view.  This happens even on super fast hardware.

The open question is why so slow?  I might guess that those textures have to be sent down to the card again, if they were aggressively culled and freed when the camera was looking away.  But the total amount of texture is not that large; there would be no reason for the paging system to have freed them, they should still be with OpenGL.

So, two important questions:
1. Doesn't this happen for everyone?  I can't imagine there's anything special about our machines.
2. Is there any way to tell the paging system to NOT free tiles so aggressively?  To keep a modest number with OpenGL, so that you can look back and forth without thrashing and losing system responsiveness?
Adam W Adam W
Reply | Threaded
Open this post in threaded view
|

Re: Critical issue with paging and horizon!

Try setting your OSG_MAX_PAGEDLOD environment variable to something higher (default is 300 if I remember correctly).  Also, try changing your loading policy to "preemptive" since that way the current LOD is loaded first.

-Adam
Ben Discoe Ben Discoe
Reply | Threaded
Open this post in threaded view
|

Re: Critical issue with paging and horizon!

Wow - thanks Adam, that made a huge difference.  I find that if i set TargetMaximumNumberOfPageLOD to 1000, then the BlueMarble imagelayer will fit in memory without thrashing, for a viewer that doesn't change position.  For OpenStreetMap, i had to go to 2000.

I am baffled by the low default of 300, but i guess that's a question for the OSG mailing list.  Perhaps it's acceptable for elevation-only datasets, or something more common in the wide world of OSG.  It definitely isn't usable for even a single osgEarth ImageLayer.  We may want to emphasize this in the docs.  I just looked, and neither "OSG_MAX_PAGEDLOD" nor "TargetMaximumNumberOfPageLOD" appear anywhere in the osgEarth documentation.