Unfortunately for our use cases VirtualPlanetBuilder is not a usable solution
The key is for us is ours is done on the FLY ( for most users) and with live data is not at that time gridded (we do that on the fly as art of our process) Most of our users simply cannot use pre-built data they live in different world to traditional vis-sim where their source data changes daily, hourly and in many cases has live feeds Many of our users also have no write permissions apart from the temp dir And because of certain operations and calculations that are done on our data we have to have very precise control of what happens and what we return. ( cannot say much on this sadly due to the nature of the tools) 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 11:44 AM To: OpenSceneGraph Users Subject: Re: [osg-users] flt-exporter: Index outofrangeinVertexPaletteManager 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.or g _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
