HI Vincent, PagedLOD does repeated request tiles on each frame till the request is served or camera moves away and the PagedLOD child is no longer needed. Normally this overhead is not a significant factor, but if you have hundreds of such failing requests on each frame I can see that this might take longer. The DatabasePager deliberately doesn't black list as it has no way of knowing if the failure is just temporary or not - for instance a temporary drop in http connection isn't something you'd want to effect you app for the life of it.
If you wanted to black list this files yourself you could write a Registry::ReadFileCallback that catches failed attempts to read files and then stores the filename in a black list that it checks against in future attempts to read files. Robert. On Wed, Dec 9, 2009 at 3:55 PM, Vincent Bourdier <[email protected]> wrote: > Hi Robert, > > Thanks for the answer, for the moment I don't have any piece of time to > spend on that, so I just set > databasePath myself. > > I have a last question : > If a graph, containing thousands of pagedLod nodes is loaded, but some > pagedLod nodes can't find their > children because the file do not exist... Will the render loop be affected > because the loader thread is trying > again and again to load theses files ? > I get a scenegraph like that, and the loading time is very very slow... but > I know there are about 3000 files missing > (on a 30 000 files graph) but I just would have a confirmation because it > needs a lot of time to arrange the graph to remove > the inexistent children. > > Thanks for your help. > > Regards, > Vincent > > Robert Osfield a écrit : >> >> HI Vincent, >> >> On Tue, Dec 8, 2009 at 5:56 PM, Vincent Bourdier >> <[email protected]> wrote: >> >>> >>> So, why the path is not relative ? I understand the behavior, but the >>> path >>> is not a relative path so it can't work as you described it. >>> >> >> The child will be stored relative to the parent, and the path should >> reflect this even in it's absolute form. There is a little twist in >> this in that the OSG has to cope with paged databases being pulled in >> from http and then cached on the local disk, so the parents might be >> loaded from the local disk, but the children haven't been downloaded >> and cached yet so still sit on the http path, so you have to use the >> http paths in the DatabasePath to be able to retreive them. The >> osgDB::FileCache automatically remaps http files that have been cached >> so it's still is able to find them, and also their children that >> aren't local. >> >> All this functionality is there inbuilt into PagedLOD + osgDB, as is >> managed automatically, while complex the intention is to hide this >> complexity from users. If you want to start digging into the the low >> level side of this functionality then you'll need to accept you'll >> need to learn about the ins and outs of how it all works. >> >> Robert. >> > > > __________ Information from ESET NOD32 Antivirus, version of virus signature > database 4672 (20091209) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > _______________________________________________ > 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
