Hi Glenn, On 1/5/07, Glenn Waldron <[EMAIL PROTECTED]> wrote:
One thing I would really like to see is "lazy rendering" support. Let me explain.
You can do this even with the present osgProducer, what is required if the app to decide whether to render a new frame or not. osgViewer also gives you control of when frame happens so will also support this type of usage. There are a couple of missing items to make "lazy rendering" easier though. When I get more into the even driven usage side of osgViewer I'll be looking related issues. Perhaps a specific example of doing lazy rendering would be appropriate to show how to do it.
I use very large, paged datasets with hundreds of thousands of buildings and other features. Paging speed is a higher priority than frame rate. My apps are always event-driven, there's no need to render continuously; I would rather render a frame only when absolutely necessary: the camera moves, a tile pages in/out, the window resizes, etc. When rendering a new frame isn't necessary, I would like the opportunity to give as much horsepower as possible to the pager (or back to the OS). Perhaps an alternative would be the ability to decouple the paging thread from the rendering loop when you have multiple cores/procs as your disposal.
The DatabasePager already runs as a separate thread and you can control how OpenGL objects are created too - the later is critical as for real-time apps one must hit a solid frame rate and never drop a frame, so you have to incrementally upload new texture objects/display lists. For you usage you just need to turn off this incremental uploading, and allow a whole subgraph to merged on the next frame. This later approach drops frames, but it does mean that data is brought in much more rapidly. Robert. _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
