Hi Rafa, W.r.t subclassing DatabasePager and DatabaseRequestHandler, I'm open to changing some methods to virtue as long as they are methods that are called often.
Alternatively it might be that a small tweak to the design of DatabasePager & DatabaseRequestHandler would help avoid the need for subclassing. For instance using calbacks to override specific bits of functionality rather than forcing subclassing is one way. I also consider DatabasePager something that is not cast in concrete, it works well for a range of usage styles, but I'm certainly open to suggestions as to how it could be further improved. Areas of interest to me are use of multiple database reading threads, the possibility of multi-threading texture/display list generation using shared graphics context. I am however really busy right now, so can't get embroiled in any complex topics as I simply don't have the bandwidth available. Robert. On 10/24/06, Rafa Gaitan <[EMAIL PROTECTED]> wrote:
Hi, we have coded, some similar as you describe, we use as Robert said a Quad tree approach, and we generate inside a "fake readNode plugin" our geometry, and then we send a callback to notify that tiles are created and they need the data (this is done in that way becouse geospeatial data management is inside Java, and we need to generate textured and elevation tiles on demand, depending of the layers loaded on Java application). That system works fine, becouse we cache textures in jpg or png formats and elevation data in geoTiff format. The main problems of the system are: - The system ask progressive for data (from less level to high level) and if data is not cached then the delay is elevated. - The other problem is when you are near to the planet, viewing the current loaded layers and you add a new layer, which not have any cached tiles. For the last we have modified the DatabasePager to support the request for the layers of the tiles, in the same way as the PagedLOD asks for childs, the system asks for layers, and this not blocks viewing and the highest levels are first processed. I'm not sure if is the better solution but works so fine for the most common layer operations (add, remove, reorder, change opacity, enable/disable). Hope this helps to you... Robert, I have a question about subclassing DatabasePager.. I tried to subclass Pager, to add this modifications, but some methods are not virtual, and the other problem is that the DatabaseRequestHandler not have new methods (obviously :D), but that implies to make a dynamic_cast inside traverse of our TilePagedLOD, to do this new functionality. There is any way to modify osg Paging to extend the functionality and not repeating the same code? By now my solution has been to repeat the DatabasePAger code, and modify it. Thanks, Rafa On 10/24/06, Jason Beverage <[EMAIL PROTECTED]> wrote: > Hi Chris, > > I'd be interested in taking a look at them just to see what happens. > > Thanks! > > Jason > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Chris Hanson > Sent: Tuesday, October 24, 2006 3:40 P > To: osg users > Subject: Re: [osg-users] Choosing correct PagedLOD child > > Robert Osfield wrote: > > Hi Jason, > > The PagedLOD node is designed to incrementally load level of detail > > levels as not to leave null children and to avoid popping straight > > from low level of detail to heigh level of detail. Chris Hanson has > > done some custom work which circumvents this for his own app, but its > > not something that is in the OpenSceneGraph core itself. > > I'd be happy to share my mods with anyone who wants them, they are > precisely what you > describe. > > > Personally I'd create a quad tree with the each PagedLOD only have two > > children, the low level of detail which is always present, and the > > external tile, this external tile would be a group contain four > > PagedLOD's. You code could procedurally generate this without the > > need for complex code to circumvent the way the core OSG works. > > Quad trees are generally well suited to most databases anyway in terms > > of balancing culling and LOD management. > > I've been considering this approach too. > > > Robert. > > -- > Chris 'Xenon' Hanson aka Eric Hammil | http://www.3DNature.com/ eric at > logrus > "I set the wheels in motion, turn up all the machines, activate the > programs, > and run behind the scenes. I set the clouds in motion, turn up light > and sound, > activate the window, and watch the world go 'round." -Prime Mover, > Rush. > _______________________________________________ > osg-users mailing list > [email protected] > http://openscenegraph.net/mailman/listinfo/osg-users > http://www.openscenegraph.org/ > > _______________________________________________ > osg-users mailing list > [email protected] > http://openscenegraph.net/mailman/listinfo/osg-users > http://www.openscenegraph.org/ > _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
