Hi Gordon, If you data is regular grids then you may well be able to use osgTerrain and have it build the geometry at the resolution you required. osgTerrain::TerrainTile uses vertex arrays, draw elements indexing and VBO's. The algorithm used for generating the geometry is still in it's infancy so doesn't do any fancy downsampling - just straight decimation, but it's produces pretty reasonable results as is so is usable for most purposes.
VirtualPlanetBuilder when used with the --terrain spits out database that are stored with osgTerrain::TerrainTile's instead of traditional polygonal data. It's already generated multi-terrabyte databases that can be browsed online at a solid 60Hz with the standard osgviewer. The nice thing about using osgTerrain::TerrainTile's is that as we update the implementation in osgTerrain over time the rendering quality and speed will only improve without the need for rebuilding the database. Given the above example that already works I would have though a system could be built that pulls in other types of data and have custom reader build osgTerrain::TerrainTile based tiles from this data, and let osgTerrain build the geometry for you. This might not be possible in your case, but it's certainly doable. Robert. On Wed, Dec 3, 2008 at 4:19 PM, Tomlinson, Gordon <[EMAIL PROTECTED]> wrote: > Hi Robert > > Short answer is yes we get acceptable rates (through hard work :)) > using geometries with indexed array's, > > Basically we have a terrain handling system that is capable of handling > the world and doing this on the fly from elevation sources such as DTED > 1/2/3 sub meter Lidar data etc and a system that matches this to very > hi-resolution satellite imagery again up to world coverage, our system > handles the reading, conversion, paging, LODing etc. this is all on the > fly from the raw data ( or saved of cached from our paging system ) so > basically the amount of data we can be handling is in the hundreds of > millions and more of points and tri's and terra bytes of imagery, > > Of course this is not all on the card or in memory we HAVE to manage > that :), but the nature of what we do having to be live ( for many) on > data that's maybe minutes old for many users means we have to be very > dynamic in our data handling, The faster paths would be great but in our > case not a reality at this time for us > > We get acceptable rates we don't need 60hz we can live with 15-20 and > thus we have built in checks to ensure we meet those by using our > dynamic on the fly loading system complexity handling ( also depends on > how much data the uses is throwing at us at any one time) > > So we build out geometry on the fly using arrays that are stored in our > fast large paging system as they are read and then feed to geometries > with LODS that have do all the normal stitch to lower levels LODS etc > now we don't change every ting every frame ( we used have a total CLOD > solution but that has other limitations) but have no guarantee on the > life of an thing in the scene :) > > Currently the only data that goes thru the normal OSG read node mode is > some of feature data that has models, and next year we hope to add > feature data to our paging and memory handling systems so the we will be > able to handle much more feature data to match out elevation and imagery > capabilities etc > > > for us right now we havie something that works and down the road I'm > know we will look to improve things adopt newer higher performance ways > were possible > > > > Gordon > > __________________________________________________________ > Gordon Tomlinson > > Product Manager 3D > Email : gtomlinson @ overwatch.textron.com > __________________________________________________________ > (C): (+1) 571-265-2612 > (W): (+1) 703-437-7651 > > "Self defence is not a function of learning tricks > but is a function of how quickly and intensely one > can arouse one's instinct for survival" > - Master Tambo Tetsura > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Robert > Osfield > Sent: Wednesday, December 03, 2008 10:37 AM > To: OpenSceneGraph Users > Subject: Re: [osg-users] flt-exporter: Index > outofrangeinVertexPaletteManager > > Hi Gordon, > > On Wed, Dec 3, 2008 at 3:25 PM, Tomlinson, Gordon > <[EMAIL PROTECTED]> wrote: >> Not using display list our data is too dynamic > > So you have a large amount of data being sent to the graphics card each > frame with glBegin/glVertex/glEnd? > > Does it performance acceptably? > > How much data are we talking about here? > > Robert. > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or > g > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
