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
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
