Hello, I' m trying to build a terrain + models database available throug web, in order to minimize bandwith, so I' ve built the terrain using the following optiions:
osgdem --image-ext jpeg --RGB_24 -O "JPEG_QUALITY 20 compressImageData" ....... -o prova.ive this way in all the .ive generated, the texture should be compressed in jpeg and included in the file. Results are consistent and the individual pages much smaller than the ones built using .dds default compression osgdem --compressed ...... -o prova1.ive the problem arise when running those dataset: unfortunately, the memory footprint of the jpeg one is much bigger than the dds one (3-5 times bigger) (desumed by what windows reports as process size) and , while in the first step the jpeg one si faster to load (adsl testing) rapidly , because of the memory used, it starts slowing down up to becoming almost unusable. I tried to dig into the code, trying to compare the jpeg an dds loader codes, but it seems to me they are similar, apart from the jpeg is probably keeping uncompressed image data around. I tried also to force setting internalFormatMode=USE_S3TC_DXT5_COMPRESSION;unRefImageDataAfterApply=TRUE inside the ive loader without success (similarly to what Laurent expose on another thread) I also am trying to add a dds on the fly compression step to the jpeg loader but up to now it is simply too slow (the code has been taken from osgconv compress visitor) You can experiment the two examples: dds: osgviewer http://3d.cineca.it/storage/terrain/demo/out_run_2/demo2.ive jpeg osgviewer http://3d.cineca.it/storage/terrain/demo/out_run_1/prova.ive on my win XP machine (osg 2.2 nad vpb 0.9) the first stay round 50-60 Mb of memory, the second quickly go over 300 500 Mb Thanks in advance for any hints Luigi Calori Robert Osfield wrote: >HI Laurent, > >The ReaderWriter::Options is the wrong place to go look for forcing >texture compression, as this only affects the loaders, and none of >these are set up to doing anything when being passed these string you >are trying. I don't understand where you got this idea from. > >osgconv has support for doing texture compression. Try: > > osgconv mymodel.flt --compress-dxt3 mymodel.ive > >Robert. > >On Dec 7, 2007 4:09 PM, Laurent Di Cesare ><[EMAIL PROTECTED]> wrote: > > >>Hello, >> >>I'm encountering performance problems when loading lots of textures in >>my scene. >>I've been trying to set options like internalFormatMode to >>USE_S3TC_DXT5_COMPRESSION, but I can't see any effect, and wonder what >>syntax I should be using: >> >>If I call >> osgDB::ReaderWriter::Options* pOptions = new >>osgDB::ReaderWriter::Options(); >> pOptions->setObjectCacheHint( >>osgDB::ReaderWriter::Options::CACHE_ALL ); >> pOptions->setOptionString( >>"internalFormatMode=USE_S3TC_DXT5_COMPRESSION;unRefImageDataAfterApply=TRUE;useHardwareMipMapGeneration=FALSE" >>); >>I can't see much of a result, and I've been crawling in the source code >>to try to find where this is parsed without success. >> >>I've delved a little into the code and found that only ive and osg >>plugins seem to handle these options. Would it be possible to parse >>these options at the osgdb level rather than the plugin level? >>Also, I am not sure whether it is possible to cache Texture objects in >>osgdb. Images are correctly cached, but operations like rescaling >>textures seem to be called several times for the same image. Is there a >>way for me to explicitly call a cache on the Texture objects to avoid >>such rescaling? >> >>Thanks in advance, >>Laurent Di Cesare. >> >>_______________________________________________ >>osg-users mailing list >>[email protected] >>http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> >> >_______________________________________________ >osg-users mailing list >[email protected] >http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
