HI Vaclav, PagedLOD is designed to be used with the first child being the lower level of detail, the second the next up and so on. If during traversal the LOD range requires a higher LOD child that isn't available yet a request is made to the DatabasePager (Which runs with it's own dedicted thread) to load this child and to ensure that there is something to render in it's place while wait for the new child to be load the next level of detail down is chosen i.e. the child preceeding it in the list. On each frame that that requested LOD child is still hasn't been loaded the next level of down will be continue to be chosen and request for load is renewed. Once the requested child has been loaded it will be merged during the update traversal and finally this child will be chosen.
Robert. On Tue, Jun 14, 2011 at 6:12 AM, Vaclav Bilek <[email protected]> wrote: > Dear Osgers, > > Based on my exploration I found interesting behavior of PagedLOD traversal. > In some condition the PagedLOD displays incorrect child (child out of > specified distance range). > > I am curious if I did something wrong, if it is intended design or if I > found a bug. > > Please imagine following case: > > (PagedLOD) > | > +--------------------------+------------------------------+ > | > | | > name : (lowerlod) (higherlod) (extralod) > range : 5..10 0..5 > 0..11 > file : lowerlod.ive higherlod.ive extralod.ive > > Also please consider that the camera is in distance of 7 from the PagedLOD > center. > > Put this scene to the viewer and observe how the traversal behaves: > > Traversal 1: > - When the PagedLOD went traversed the 'lowerlod' gets loaded in request to > the database pager (lowerlod.ive). > > Traversal 2: > - In this next traversal of the PagedLOD the 'lowerlod' is already in the > scene and because it fits to the range (5 <= distance < 10), it gets > traversed and displayed. > - In next step the child 'higherlod' is determined to be loaded and the > database pager is asked to load the file higherlod.ive > > Traversal 3: > - The 'lowerlod' still fits into the range, so it is traversed and > displayed. > - The 'higherlod' is already loaded, however it does not fit to the range it > is not traversed - but only for a moment. > - Finally here the problem occurs. Although the 'higherlod' does not fit > into the range (0 <= distance < 5) it is traversed and displayed because of > this code (somewhere in PagedLOD.cpp: PagedLOD::traverse() ): > > //running conditions at traversal #3 > // lastChildTraversed == 0 // <= this is recored when the 'lowerlod' is > determined to be traversed&displayed > // numChildren == 2 // this is size of the std::vector > container _children when both 'lowerlod' and 'higherlod' > ... > // select the last valid child. if (numChildren>0 && > ((int)numChildren-1)!=lastChildTraversed) { if (updateTimeStamp) { > _perRangeDataList[numChildren-1]._timeStamp=timeStamp; > _perRangeDataList[numChildren-1]._frameNumber=frameNumber; } > _children[numChildren-1]->accept(nv); } ... > > What is interesting: > From my user point of view the LOD should be displayed only if it fits into > specified ranges. The PagedLOD is understood as LOD with on-demand loading > capability. And here the PagedLOD does not hit my user expectations. Maybe I > construct the scene wrong but even if I put the 'lowerlod' before or after > the 'higherlod' or on the end after the 'extralod' the behavior stays the > same. > > I did little change by adding new condition and now it works as I expected > Modified code fragment (same place as above): > ... > // select the last valid child. if (numChildren>0 && > ((int)numChildren-1)!=lastChildTraversed) { > if (_rangeList[numChildren-1].first<=required_range && > required_range<_rangeList[numChildren-1].second) // <= this is the > additional condition > { > if (updateTimeStamp) { > _perRangeDataList[numChildren-1]._timeStamp=timeStamp; > _perRangeDataList[numChildren-1]._frameNumber=frameNumber; } > _children[numChildren-1]->accept(nv); > } > } ... > > Now the child gets traversed only if it fits into the specified range. > > Hope my english is enough to explain this. I welcome any comments and very > curios if anybody observed similar problem. > > Best regards > Vaclav > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
