Hi Ulrich, On Tue, Jun 2, 2009 at 12:58 PM, Ulrich Hertlein <[email protected]> wrote: > Would you agree that the RefNodePathList is the better long-term solution?
I think it is. I was just pondering on another DatabasePager design issue (FileCache and new DatabaseRevisions funcitonality) and solution to your problem popped into my head... funny how the brain can sometimes work on multiple tasks at once :-) It occurred to be that solution for the problem is not to take a RefNodePath during the database thread itself as this itself is not thread safe as the parent path that you have to walk may well become invalidated during the assent up the parent path from the PagedLOD node that you are mean to add the new loaded subgraph to. One still needs a RefNodePath though, and the time to record this is when you due the orignal cull traversal and make the DatabaseRequest in the first place. We already record a ref_ptr<> to the PagedLOD(Group) that we wish to add the loaded subgraph to, we just need to record the whole parent path - we should also be able to just reuse the NodeVisitor's whole NodePath rather than having to traversal the parent path that might not be unique. Since you won't be deleting the scene graph while the cull traversal is running then it should be safe to make the ref node during this phase. There is one gotcha though, if we record the whole parent path in the DatabaseRequest then you won't be able to delete the scene graph until the DatabasePager has finished with it, and it won't discard loaded subgraphs until you merge them. This suggest that we might need to have a mode in DatabasePager to just flush itself of everything it's go retained. Another possible soluition might be to make the DatabaseRequest an Observer of the nodes into the requested PagedLod's NodePath and have it prune these in a thread safe way such that the database thread can't get an invalid parent path. This is route would be more complex to implement but would avoid the issue of not being able to delete scene graphs. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
