Hi Jaime, my last project was a car simulator for Williams F1. And I want to give you few hints.
In theory, quad tree spatial terrain database suits best, and this is output from known terrain tools from Presagis, TerraSim, TrianGraphics - they do this automatically for You. So this is the first answer. However, from my last project, and this is based on lots of experimenting with OSG and the latest graphics hardware, I found that a flat structure - nodes by nodes - can perform almost with double performance, if they are meshed - by meshing I mean here preparing the geometry into large meshes based on material, textures (state). On todays hardware you can have large terrain models (all into memory) like this, no paging. And for this you can use Presagis Creator or the modeler from Remo 3D - I assume you will use the standard format for this which sits in the sim industry for decades, like OpenFlight, which is good for modelling and you can further optimized it with OSG for rendering into formats like .ive, .osgb etc. If you have REALLY large terrain model then you can consider some formats that supports paging. So far I am familiar with TerraVista and Presagis TerraPage, which has it as quadtree and something called smart mesh - this is here and available for decade or so and I still think it is the best and the most lightweight LOD paging schema and supported by the native OSG PagedLOD. So I guess You should tell us more about your terrain model, how you build it or you plan to build it so we might have more hints for you Hope these helps Cheers, Nick On Wed, Apr 23, 2014 at 11:00 AM, Robert Osfield <[email protected]>wrote: > HI Jamie, > > On 23 April 2014 09:58, Jaime <[email protected]> wrote: > > What about 'pools'? We have been thinking about having a pool system to > manage trees (lamps, cars, etc.). We would render only the objects that are > near the player. > > The nodes of the scene graph are pretty lightweight, it's the geometry > and textures that are large so what you want to achieve is sharing of > the geometry and textures (and other state) but you generally don't > need to attempt to save internal nodes in the scene graph. This means > that when you build the scene graph build the internal nodes so it > provides well balanced culling - via both spatial and LOD culling and > share as much of the leaves and state as you can. If you have a > static scene then you probably won't need to worry about managing a > pool of geometry and state apart from for the purposes of building the > scene graph in the first place. > > If you are needing to page the database because it's far too big to > fit in memory then there may be value in managing a pool that is > shared. The osgDB library has a cache which you can use for this > purpose, or you could create a pseudo loader to managing the > instances. > > Robert. > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- trajce nikolov nick
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
