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:

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.


Flightgear-devel mailing list

Reply via email to