-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andy Ross schrieb: > 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.
I'm not against lossy compression. But JPEG hasn't the best algorithm for our use. JPEG2000 might, but I don't know enough about it. > 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. Usually is any lossy format for inbetween dumb. > 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. This a point for lossy compression, not one for JPEG... One important point to remember is, that every lossy compression can compresse some data exact (the decompressed data...). So when we find a compression algorithm that creates decompressed data that is good enough for us, we can use it (even when the compressed data is in JPEG format). For our case that compressor must not rely on special optical tricks (because these get destroyed when they are used as an texture). If we find an JPEG compressor that fullfills this requirement, it's fine. If we don't, we need a different format. (If we find one, there's still a possible problem: people who don't know this special requirement are likely to submit wrongly generated files...) As only these special cautions allow one to use JPEGs, it's much saver to say: "kids, don't try that at home!" CU, Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB+9HDlhWtxOxWNFcRAp0QAJ9MHzxlU0dvXQjIoOtBWXT3jtoz+gCfbliO bUCWTF+HZdZs7as8h3NWwv8= =1us6 -----END PGP SIGNATURE----- _______________________________________________ Flightgear-devel mailing list [email protected] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
