Hi, Firstly a tip from building large databases myself, make sure you source imagery has been optimised as much as possible. I have found ecw files are much faster to process than other formats due to their exceptional speed in creating arbitrary overviews. If you are using GeoTiffs make sure you have created 'overviews' (I cant think of the correct name) for them (basically a set of mipmaps stored inline). This make a big difference to generation speed. I would also suggest you look pay attention to what output format you use for your imagery. I have found that compressing the output imagery takes the greatest amount of CPU time of the build process. If you use no compression, the output will be massive. I use these settings: --compressed-dxt1a (of dxt1 if my data completely covers the area being generated or I am using layer inheritance). --compression-quality-fastest (I honestly cant see a visible difference compared to the high quality mode, but runs almost an order of magnitude faster) --compressor-nvtt-nocuda (I run on a machine with no or poor graphics card)
Now on to your question regarding options: --layer-inheritance [Lowest/Nearest/No] This comes in to play when the source data for a tile does not cover the full extents of the tile. This option determines what you see in the 'empty space'. When set to 'No', the empty space is left empty. If your output format doesn't include an alpha channel, the 'empty' space will be black, if your output format does support alpha, the empty space will be transparent. When 'Lowest' is specified, the lowest resolution data available for the area if used to fill the gaps. When Nearest is specified, the nearest resolution data available for the area if used to fill the gaps. Note that when you use optional layers, it really only makes sense to use 'No'. --set <setname> used by itself, I haven't been able to figure out what effect this has. --optional-set <setname> When used in conjunction with --set (i.e. specify both with the same value: --set MySet --optional-set MySet) you imagery layer is stored in an external (i.e. not in the .ive or .osgb file) directory structure. This allows a tile to be loaded without having to load all the optional images associated with it. --optional-image-layout [inline/external-set-dir/external-local-dir] --optional-elevation-layout [inline/external-set-dir/external-local-dir] This determines how optional layers will be written to disk. Using inline stores the optional layers within the .ive/.osgb file. These seems to defeat the purpose of optional layers but I am probably just missing the use case for this. >From my experience both external-set-dir/external-local-dir produce the same >output, but this may have changed since I last played with these options. I >think the intention was that external-set-dir places files for each optional >layer in a folder named after the set, while external-local-dir places all the >optional layers in a single directory structure. This needs to be confirmed >though. >> How does the idea of optional layers work? I assume it is possible to plug >> in optional layers for DEM and for textures independent? It is, though I haven't personally tried optional elevation data. >> Do I need a special terrain technique to use such a database with optional >> layers, or can I use the standard osgViewer? I have written my own terrain technique to control the display of optional layers (a sub-class of GeometryTechnique) but I think you can access up to three optional layers via a MultiTextureControl node used to decorate the generated scene though I haven't used this myself. I am pretty sure the default osgViewer doesn't provide access to this functionality though. You should also look at the osgTerrain::TerrainTile::setTileLoadedCallback() method and the default implementation WhiteListTileLoadedCallback which can be used to control the loading of optional layers (I have also implemented my own call-back). I will also add a couple of comments not directly related your questions: I would suggest you look closely at creating your own TerrainTechnique. Subclassing GeometryTechneque is pretty easy and will give you a lot more control. While this was quite a bit of work, I have managed to dynamically merge the output of multiple VPB databases at runtime. This provides a lot more flexibility to 'mix and match' different datasets and greatly simplifies the process of adding a bit of new data. As a side note, once you generate a large database moving it about is very painful due to the huge number of small files it creates. To help with this I place my databases into an archive format (I think the largest archive I have created is ~150gig), though this is probably not practical when your output will be several terabytes. If you decide to look into this, a couple of pointers / warnings: - you will need to convert the relative file names for optional layers into filenames relative to the root of your archive. - osga does not scale well to very large sizes. Just opening the file can take minutes while the index is read. - You cannot read optional layers from an osga file via the tile loaded call-back as it does not support re-entrant loading of files. - I have implemented an SQLLite based OSG archive format which solves these problems, but does get slow to build once the output databases grows into the 10's - 100's of gigs. I intend to submit this format at some stage but it is still sitting in the 'to-do' pile. I am happy to share the code with anyone that is interested though. Hopefully this helps a little. Let me know how you get on with such a large data set. I am interested to know how it goes. Cheers, Brad -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Torben Dannhauer Sent: Friday, 1 July 2011 3:40 PM To: [email protected] Subject: [osg-users] [vpb] Questions regarding setname, optional layers and layer inheritance Hi, I'm plan to process a large database with more than 1 TB of source data. Therefore I don't want to include all source data into a single database but would like to have a modular database with "optional" parts. I browsed the VPB sources and discovered somer options I do not understand, I would be glad to get some basic hints.. The unknown options are: --layer-inheritance [Lowest/Nearest/No] : What does this option cause? --set <setname>, What is a set name? what is the difference to the comment string I can add to the topmost node of the database via --comment? --optional-set <setname> --remove-optional-set <setname> --optional-image-layout [inline/external-set-dir/external-local-dir] --optional-elevation-layout [inline/external-set-dir/external-local-dir] How does the idea of optional layers work? I assume it is possible to plug in optional layers for DEM and for textures independent? What is about the layout (inline/external-set-dir/external-local-dir) Any hint wherer to look to learn how that works? Do I need a special terrain technique to use such a database with optional layers, or can I use the standard osgViewer? As "return of investment" of your help, I will write a usage example in the VPB wiki as soon as I understand how that works. Thank you! Cheers, Torben ------------------ Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=41087#41087 _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ------------------------------------------------------------------------- DISCLAIMER: This e-mail transmission and any documents, files and previous e-mail messages attached to it are private and confidential. They may contain proprietary or copyright material or information that is subject to legal professional privilege. They are for the use of the intended recipient only. Any unauthorised viewing, use, disclosure, copying, alteration, storage or distribution of, or reliance on, this message is strictly prohibited. No part may be reproduced, adapted or transmitted without the written permission of the owner. If you have received this transmission in error, or are not an authorised recipient, please immediately notify the sender by return email, delete this message and all copies from your e-mail system, and destroy any printed copies. Receipt by anyone other than the intended recipient should not be deemed a waiver of any privilege or protection. Thales Australia does not warrant or represent that this e-mail or any documents, files and previous e-mail messages attached are error or virus free. ------------------------------------------------------------------------- _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
