[osg-users] using jpeg textures

[Luigi Calori]

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
><laurent.dicesare at masagroup.net> 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
>>osg-users at lists.openscenegraph.org
>>http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>    
>>
>_______________________________________________
>osg-users mailing list
>osg-users at lists.openscenegraph.org
>http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
>  
>