Mao wrote: > 1. In the example of osgDEM, I infer that osgDEM processes tiff > format only.
Are you talking about for image drapes? osgDEM supports many formats for images and DEMs. > But tiff uses 32-bit offset which limits its size to 4G > bytes. Most of our data are ERDAS img file or rrd file, which are huge > in size. Yesterday, we processed an img file of size 20G bytes, and > gdal_translate it to a 21G bytes tiff. That confused me. How can VPB > handle extra bytes? Was this an image or a DEM stored as img? You can always use ECW for large images, which doesn't have a 4G limit. > 2. Another thing is that, texture files we got sometimes are in > pieces, and we should use gdal_merge.py to merge them into one big tiff. > According to the source code, VPB can handle only one texture file. Can > we use multiple texture files? I can't recall if this works. Did you try it? You should be able to try it with a couple of small files. > 3. The last question is when applied with “--Terrain” or > “—HEIGHT_FIELD” options, there is no texture at all. Can we encapsulate > both texture and DEM data into one output file? I've been building textured terrain models via --terrain successfully. > And it seems that > osg::HeightField does not provide height = getHieghtAt(terrain.x, > terrain.y) method. I can't answer this. -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ "There is no Truth. There is only Perception. To Perceive is to Exist." - Xen _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
