Hi Wojtek, On Mon, Nov 23, 2009 at 2:34 PM, Wojciech Lewandowski <lewandow...@ai.com.pl> wrote: > But I would strongly defend merits of arguments in the post. You say we did > wrong, but whats you recommendation on mixing many intersections with > rendering ? Its very common scenario. How should we tackle it, if current > approach is wrong ?
The right approach is a difficult one. Getting a paged scene graph to work with intersections at highest resolutions and at the same time manage things for rendering with requires just the appropriate LOD child for the needs of visuals is awkward. I know often vis-sim apps don't even try to mix the two, and have a separate process entirely for dealing intersections as for doing the visuals. Some sims even run the visuals and intersection testing on entirely different machines. Other sims use entirely separate databases for intersection testing and visuals. Then there are others that use a height field for height above terrain testing... If you do want to mix the two then you need to ask questions about how you want to do intersections and how your thread them. Do you do intersections in the main loop? In a separate thread? Do you run the intersections multi-threaded? I.e. multiple intersections traversals at one time? Should the intersection traversal wait to load external tiles to get the result, or should then just return the intersections for what is already loaded into memory. What approach you will want to use will depend upon all of this. > Second important issue for me is usage of _name in scene graph. I always > expected that _name is reserved for users and its a normal rule in all Scene > Graph implementations that libraries do not change it. Names are ususlly > used to identify certain portions of models and hook up the code properly. > Thats something that provide standard linking mechanisms between artists and > programmers works. I agree, but... in this instance the DatabasePager's algorithm was about deleting a subgraph that would no longer have any role to play in the applications life so the changing of name should never have got outside that algorithm as the subgraph would be just deleted. So it is in theory just a black box, how it does it's job shouldn't effect anything else. Alas in this case it looks like the algorithm in DatabasePager is flawed. > Please also note that we use cache becuse we otherwise were loading PageLOD > files twice. Is it reasonable ?. Using a cache to prevent a subgraph from being deleted defeats the load balancing that the DatabasePager will be attempting to do, so it's a dangerous thing to do - it's a recipe for relentless growth in memory usage. > Even if we skip intersections, other > situations are also possible. For example we may have few highly detailed > special PageLOD tiles with ariports which we want to preload and keep in > memory for whole application runtime. So we modify readFileCallback to work > for such cache and return these preloaded models each time thery are > requested. Use of the cache in conjunction with a paged database should be used very sparingly and for only very specific types of assets. It does also open the question of how DatabasePager should deal with such datasets, without lots of reflection on the issue I can't say. I can say in the design and development of DatabasePager I have made the assumption that it'd be the master of the PagedLOD's and manage all reading and expiring, and not have code on the outside managing things in a parallel. It's worth noting that PagedLOD has settings that allow you to control what happens with expiry - so you can individually switch off the expiry. > Their names will be changed as well and "NeedToRemove" scheme > stops working anyway. I suspect the "NeedToRemove" scheme is only scratching the surface of the issue of apps that try to mix paging and caching. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
