[osg-users] Lazy Rendering with pagedLOD databases

Glenn Waldron gwaldron at gmail.com
Wed Jul 30 08:03:55 PDT 2008


John,

Digging into my memories on the subject...

One issue is, like you said, keeping data from paging out when the renderer
is idle. One approach might be to force a cull traversal every so often, or
to visit the scene graph and manually update the timestamps on your
PagedLODs. There may be more to it however.

The other issue is making sure the pager completes all the tasks it has
queued up. The pager does a little slice of work each frame in order to
avoid frame rate hiccups. So when you go to render on demand, you have to
keep looping until the pager goes "idle" ... i.e. its queues empty out. You
can query the state with requiresUpdateSceneGraph(),
getFileRequestListSize(), et al.

Now, my experimentation in this area was with an older version of OSG and
Robert has refactored the pager since then. It ended up being a much more
complex task than I anticipated.

Glenn

On Wed, Jul 30, 2008 at 10:12 AM, John Vidar Larring
<larring at weatherone.tv>wrote:

> Hi Glenn,
>
> Thanks for your quick reply as always:) Changing topic title to use more
> appropriate terms. See comments below:
>
> > I used to refer to the technique you're using as "lazy rendering"
> > (i.e. only render a frame when something has changed) ... try
> > searching the archives ...
>
> When searching the archives for "lazy rendering" through Google Groups and
> Gmain, I only found to posting on the subject, of which this one comments
> the former:
>
> http://article.gmane.org/gmane.comp.graphics.openscenegraph.user/8859/match=lazy+rendering
>
> > I have run into the same issue. PagedLOD children "expire" after a
> > certain period of time (default is something like 5 seconds?) If a
> > PagedLOD child has not been visited in the last N seconds, the pager
> > will discard it and revert to a lower LOD. OSG updates the
> > "time-last-visited" during the cull traversal in order to check for
> > expiration. So, if you are not continuously running the frame loop,
> > PagedLOD's will think their children have expired and will drop to the
> > lowest LOD.
> > [snip]... but at the time I never did find a good way to do this in
> > OSG without confusing the pager.
>
> Hmmm... that's what I feared. Ok, I am just thinking aloud here since this
> is a problem I really need to get solved:
>
> For real-time rendering paging out children on expery time is a good idea
> to keep memory consumption at minimum. However, this obvious does not work
> for "lazy rendering".
>
> What if the pager could be configured in the following way for "lazy
> rendering":
> * Set a "maximum" memory size osgDB::DatabasePager can occupy.
> * When a new page/sub-graph is added,
> osgDB::DatabasePager::removeExpiredSubgraphs() will remove the oldest pages
> if the "maximum" limit is exceeded.
>
> Would this be a feasible strategy? Or are there better ways/strategies to
> support lazy rendering of pagedLOD databases?
>
> Best regards,
> John Larring
>
>
> Glenn Waldron wrote:
>
>> John,
>>
>> I have run into the same issue. PagedLOD children "expire" after a certain
>> period of time (default is something like 5 seconds?) If a PagedLOD child
>> has not been visited in the last N seconds, the pager will discard it and
>> revert to a lower LOD. OSG updates the "time-last-visited" during the cull
>> traversal in order to check for expiration. So, if you are not continuously
>> running the frame loop, PagedLOD's will think their children have expired
>> and will drop to the lowest LOD.
>>
>> I used to refer to the technique you're using as "lazy rendering" (i.e.
>> only render a frame when something has changed) ... try searching the
>> archives ... but at the time I never did find a good way to do this in OSG
>> without confusing the pager.
>>
>> Glenn
>>
>> --
>> Glenn Waldron : Pelican Mapping : http://pelicanmapping.com :
>> +1.703.652.4791
>>
>> On Wed, Jul 30, 2008 at 8:39 AM, John Vidar Larring <
>> larring at weatherone.tv <mailto:larring at weatherone.tv>> wrote:
>>
>>    Hi all,
>>
>>    Background:
>>    -----------
>>    In our application the user can set up scenes ( or sequences as we
>>    call them) for playback on a timeline (e.g. seq.1 - transition -
>>    seg.2 - transition ... seq.N). Some scenes are too complex to render
>>    real-time and are recorded to movies before playback. Hence, when
>>    scenes are edited by the user all scenes are redrawn as needed
>>    rather than continuously to avoid sluggish GUI response.
>>
>>    Problem:
>>    --------
>>    _Sometimes_ when the scene is redrawn in edit mode (i.e. redraw only
>>    if needed), the pagedLOD DB (osgTerrain) drops to the lowest detail
>>    level (Ref. osg_original.jpg and osg_problem.jpg). This behavior
>>    seems to appear at randomly. In playback mode (i.e. when frame rate
>>    is constant) the problem never occurs.
>>
>>    Reproduce / Code example:
>>    ----------
>>    The problem has been reproduces in a small test program
>>    (osgtest_source_code.tgz) derived from the osgviewerQT example
>>    (since we are using Qt 4.x in our application). To reproduce: run
>>    the compiled application: 'osgtest -t <your osgTerrain db>' . To
>>    trigger refreshes, occlude parts of the window with another window.
>>    The problem typically reveals itself when at a redraw or when the
>>    window looses focus (be patient, since this happens randomly it may
>>    take some time before the problem occurs).
>>
>>    Since I'm still quite new to OSG, I'm not sure where to look for a
>>    solution. Hopefully someone will spot the obvious error in the
>>    sample code. Any advice is highly appreciated.
>>
>>    Versions:
>>    ---------
>>    OSG svn rev 8700
>>    Qt 4.2.3
>>
>>    Best regards,
>>    John Larring
>>
>>    --    This message has been scanned for viruses and
>>    dangerous content by MailScanner, and is
>>    believed to be clean.
>>
>>
>>    _______________________________________________
>>    osg-users mailing list
>>    osg-users at lists.openscenegraph.org
>>    <mailto:osg-users at lists.openscenegraph.org>
>>
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
>> believed to be clean.
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> osg-users mailing list
>> osg-users at lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>
>
> --
> Best regards,
> John
> WeatherOne
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
Glenn Waldron : Pelican Mapping : http://pelicanmapping.com :
+1.703.652.4791
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20080730/34642691/attachment-0003.htm>


More information about the osg-users mailing list