Christian Mayer wrote: > Manual Massing wrote: > > 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
Honestly, Steve is just wrong on this one. Lossy compression works just fine in moderation. The S3TC format itself is a lossy algorithm that is inferior in quality to JPEG in basically every conceivable way, and it's supported navtively by the texture hardware for goodness sake. Yes, using JPEG as an intermediate format during content creation is a dumb idea due to progressive data loss. Refusing to use it for final/shipping textures based on this advice is just dumb. Real-world 3D applications and games ship their images compressed with lossy algorithms. Has anyone actually looked at how much of the base package is taken up by SGI+ format image files? (Which have absolutely abysmal compression ratios, but that's a different argument.) I wrote a quick script at one point to recursively convert all these to default-quality JPEGs, and the savings was staggering. Something like a 75% reduction. Andy _______________________________________________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
