Hi Robert,
I understand the non-black-list behavior, this is a very good thing.
I don't have time to spend on a new Registry::ReadFileCallback ... so I
will use an other way.
I just run some tests using dataBasePath to "./" because the tree file
and the Lods files are in the same path.
It works well if the .exe which load the tree is in the same path... If
it is not, the tree loads but the DataBasePager
don't find any files... You said the path is relative to the parent...
so if I understood you well, it may works...
Am I wrong ?
Thanks.
Regards,
Vincent.
Robert Osfield a écrit :
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
__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4675 (20091210) __________
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
