Hi Luigi, The data size difference you are seeing is something I'd expect, when the jpeg plugin uncompressed the image the final image will be 4 to 8 times bigger than the equivalent OpenGL compressed texture, and it'll be that much bigger when attached to the scene graph, and when downloaded to the GPU.
Compression to OpenGL compressed texture format on the fly will only save a bit in main memory, but more down on the GPU, but its slow, and right now requires OpenGL to get involved to do the compression. If one could write a pure CPU based osg::Image compressed to OpenGL format routine then you might be able to run this from within the database pager thread. To do this you'll need the specs of the various OpenGL compressed texture formats and how to go about creating them. I'm afraid I don't have any specs on this myself. Perhaps others do. Robert. On Dec 8, 2007 2:52 PM, Luigi Calori <[EMAIL PROTECTED]> wrote: > 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 > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
