On Saturday, 29 January 2005 12:54, Christian Mayer wrote: > Manuel Massing schrieb: > > Hello, > > > >>I do have a few questions though : > >>Does the current code that you have handle texture paging? > > > > Yes, textures and geometry are paged and decompressed asynchronously in > > the background (seperate thread). The engine supports image compression > > to save IO (and possibly bus) bandwith, e.g. JPEG and S3TC compression. > > The first maybe quite taxing on the CPU, so we usually only use JPEG for > > the finest detail level textures, which account for most of the data, and > > S3TC for the lower detail levels. > > Do you know: > > http://www.sjbaker.org/steve/omniv/jpegs_are_evil_too.html
There's still no open source alternative to jpg when it comes to storage size and storage is the major issue when dealing with lots of satellite or aerial photos. I did a test with the 18 century crop texture : JPG : 1024x1024 @ 85% quality = 508.4 KB PNG : 512x512 @ level 9 compression = 630.4 KB Four times higher resolution with hardly any noticable loss in quality (even when zoomed in) and it still comes out with a smaller footprint than a PNG that is 4 times lower resolution. Sometimes size does count. What do you suggest as a replacement to JPG that will give a similiar footprint size? Paul _______________________________________________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
