HI Robert, 2011/6/15 Robert Osfield <[email protected]>
> Hi Emmanuel, > > You can certain use the OSG and paging without rendering, but the > stall in the intersection traversal you are getting has nothing to do > with rendering, it's simply the the LineOfSight algorithm is set up to > drill down to the highest level of detail. > I understand this as nothing to do with rendering, but it has to do with loading all tiles in a row instead of loading them only when there is some time available between two frames as the databasepager does. Since the intersection is done for me in the rendering loop this is blocking everything for too long. > > The LineOfSight class by default assigns a > osgSim::DatabaseCacheReadCallback the IntersectionVisitor that it uses > to intersect the scene graph, it's this ReadCallback that is reading > the external tile and causing the slow down. It does cache the > requests so on subsequent intersection tests you'll get better speed, > but for the first intersection where it has to load all the tiles > required by the intersection it will be slow, especially if there are > many levels of detail to pull in. > > You can reset the LineOfSight::DatabaseCacheReadCallback off by doing > setDatabaseCacheReadCallback(0), but this will disable it's ability to > pull in external tiles so that it will be limited by what data is > already loaded into memory. > > What you'd want in your case I can't answer - do you need the highest > level of detail to do the intersection? If so you'll need to see if > you can pre-populate the DatabaseCacheReadCallback with the tiles you > are expecting to need. If not then just reset th callback to 0, or > just use your own IntersectionVisitor traversal. > In fact, I need the highest possible resolution. But I would not mind getting this final accurate result after multiple cycles (as would be the case if I let the database pager load the tiles progressively. So I guess, just putting a camera very close to the ground on the intersection ray would be a good option. => Now, could I really just setup a Cullvisitor manually, traverse the scene with this visitor, and then perform a updateSceneGraph() call on a regular basis with the databasepager, and except the tiles to be progressively loaded this way ? Manu. > > Robert. > > On Wed, Jun 15, 2011 at 9:16 AM, Emmanuel Roche > <[email protected]> wrote: > > Hi Everyone, > > > > I think I have a very specific issue here, and I could use some help to > fix > > this: > > > > - I'm trying to compute interections with an osgEarth model using the > > osgSim::LineOfSight helper class. > > - The problem is, this helper class seems to just be freezing when > loading > > the earth tiles in the readcallback (at least, this is just taking too > > long): I guess this is because all the needed tiles are loaded > synchronously > > before one can perform the first intersection test. > > -So I was wondering if there was a way to acheive a "more real time" > > behavior using a regular intersection situation: when you have a osgEarth > > model loaded and rendered then the camera is used to decide which tiles > to > > load and the database pager will load them smoothly. And then, a simple > > intersectionVisitor can give you the current intersection result desired > > without blocking the rendering loop for ages. > > > > => But at the same time, I just don't want to render this osgEarth > model... > > it should just be an "hidden" model used for intersection tests. > > > > So I was wondering: is there a way, to easily setup a complete traversal > > loop (event,update, and cull traversal) but prevent the drawing traversal > of > > a scene ? If this possible the cull traversal with appropriate camera > > location would trigger new requests for tiles, the update traversal would > > allow the database pager to load those tiles, and I could still save the > > ressources and hardware compatibility needed for the drawing traversal... > > > > Any idea if this is possible or not or how to proceed ?? > > > > Cheers, > > Manu. > > > > > > _______________________________________________ > > 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 >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
