Обзор форматов текстурного сжатия S3TC и FXT1 и сравнение с 16-битными текстурами

Предисловие

В течение последних нескольких лет мир 3D технологий развивается очень быстро. Появляется очень много новых разработок каждые полгода, и простые пользователи не успевают за всем уследить. Компании показывают демки, в которых используются те или иные новые технологии, все очень красиво, хорошо и почти быстро, но игр, использующих эти новинки, дожидаться обычно очень долго. А мы все равно идем и достаем денежки (не только из-за демок, конечно :) и покупаем новые видеокарты, а дома "старые", которым нет еще и года, валяются где-нибудь на полке, и никому они и за $40-50 не нужны. Такой уж на сегодняшний день быстроразвивающийся мир бытового/игрового 3D. Надеюсь, он останется таким еще очень долго :).

Одним из самых интересных нововведений в современном мире бытовой/игровой 3D графики являются технологии компрессии текстур, ставшие в последнее время довольно популярными из-за возрастающих из года в год требований к объему текстур. При все увеличивающейся потребности повышения детализации в играх, распространении 32-битного рендеринга появилась необходимость в больших 32-битных текстурах, а значит и увеличении объема текстурной памяти. Только применение Truecolor текстур уже увеличивает потребность в видеопамяти в 2 раза, и также нуждается в вдвое большей пропускной способности видеопамяти. Производители графических чипов задумались, каким образом можно увеличить объем текстур, не увеличивая локальную память видеокарт и не удорожая тем самым свою продукцию. Выход нашли достаточно быстро - занялись разработкой технологий текстурного сжатия. Первой компанией, добившейся заметного прогресса в этой области, была S3 Inc. (более ранние попытки не добились сколько-нибудь значительного успеха), которая представила миру свое изобретение, назвав его "очень оригинально" — S3 Texture Compression (S3TC).

Уже сейчас это сжатие применяется в нескольких, очень популярных играх: Quake 3 Arena + игры на его движке (уже вышедшая Heavy Metal F.A.K.K. 2, Star Trek: Elite Force и другие, готовящиеся к выпуску), Unreal Tournament, Soldier Of Fortune. В перечисленных играх 16Мб/32Мб локальной видеопамяти не всегда хватает, особенно если применять 32-битные режимы и текстуры. Если кто-нибудь еще надеется на AGP, то зря — отдает он текстуры очень неохотно, небольшая надежда на будущие версии этого стандарта.

Именно из-за поддержки сжатия в некоторых играх доступна более высокая детализация. Навскидку вспоминается Unreal Tournament на Savage через их собственный API Metal (с недавнего времени и на других видеокартах через переделанный OpenGL драйвер), различные специальные уровни для Quake 3. И это — уже сегодняшний день, завтра будет еще веселее.

Для примера повышенной текстурной детализации я приведу два скриншота, где показан рендеринг с обычным разрешением текстуры и с увеличенным в 4 раза и сжатым S3TC. То есть, если нормальный размер текстуры 256х256, то увеличенная будет размером 512х512. При этом требования к полосе пропускания и текстурной памяти одинаковые или у сжатой текстуры даже меньше!

256х256 без сжатия	512х512 со сжатием

Думаю, все согласятся, что вторая картинка лучше передает четкость поверхности материала.

С момента создания S3TC и до некоторого времени, сжатие текстур было доступно только для видеочипов S3 Inc., хорошая идея не получала достойного применения, и конкурировать S3TC было не с чем. Позже появился первый (и пока последний) конкурент на бытовом рынке — технология FXT1 от другого, не менее, а скорее более именитого производителя 3dfx Interactive, Inc. Появление конкуренции всегда имеет две стороны. Первая — хорошая, появился конкурент, а правильная и здоровая конкуренция обычно двигает прогресс. С другой стороны, разработчикам приходится выбирать между двумя разными технологиями. Скорее всего, их выбор ограничится использованием S3TC как уже распространенной, благо ее вариант в DirectX доступен всем и уже используется, а для применения сжатия в OpenGL ее лицензировали все основные производители видеочипов (NVIDIA, ATi, вроде бы и 3dfx применяет), и уже воплотили ее в железе и драйверах. Так что же, заочный победитель сравнения определен? Похоже на то, если смотреть на поддержку разработчиками, да и 3dfx в последнее время что-то потеряла былую силу - никто не поддерживает ее формат сжатия.

Забегая вперед, скажу, что основное отличие FXT1 это больший коэффициент сжатия. Так как алгоритмы форматов очень и очень близки, то можно предположить, что большее сжатие было достигнуто за счет качества. Это мы с вами сейчас и проверим.

Чтобы использовать преимущества сжатия S3TC, необходимы следующие, достаточно распространенные видеокарты (или видеокарты, основанные на видеочипах):

• S3: Savage 3D, Savage 4, Savage 2000
• NVIDIA: GeForce 256 (SDR и DDR), GeForce2 (GTS и MX, Ultra, Pro, похоже и Go тоже), Quadro 1/Quadro 2 (MXR и Pro)
• 3dfx: VSA-100 (Voodoo 4 4x00, Voodoo 5 5500, Voodoo 5 6000)
• ATi: ATi Radeon (SDR и DDR).

Для FXT1 подойдут пока только вышеуказанные карты от 3dfx, но, помня про схожесть алгоритмов, можно предположить, что если эта технология найдет применение, то ее поддержку достаточно просто можно будет включить в драйверы чипов других производителей.

Условия тестирования

Тестовый компьютер — Celeron 450(4,5*100)/Chaintech 6ZIA(ZX)/96Mb PC-100/Quantum Fireball Plus KA 9,1Gb/Windows 98 Second Edition

Но эти данные практически не важны, так как основное внимание в данном обзоре будет уделено качеству.

Тестирование было решено проводить теоретическим методом, без применения реальных игр, так как в реальных условиях очень многое зависит от оптимизации поддержки текстурного сжатия в драйверах конкретных видеокарт и даже чипов. Для подтверждения этого, достаточно вспомнить декомпрессию текстур S3TC без альфа-канала в драйверах NVIDIA. А хоть какой-то игры, поддерживающей обе рассматриваемые технологии, нет, и пока не предвидится. Поэтому сравнение было решено сделать при помощи утилит, предоставляемых обеими компаниями для разработчиков. В них должно быть обеспечено эталонное кодирование/декодирование при хорошей оптимизации скорости.

При исследовании FXT1 использовались утилиты для разработчиков 3dfx от 14.09.1999. Их оригинальное название: "3dfx FXT1(TM) Texture Compression Binaries and Source Code".

Для сжатия и распаковки с помощью S3TC были использованы утилиты от бывшей компании S3 Inc."S3TC Utility/Viewer 1.1". В связи с известными событиями с продажей графического подразделения этой компании, я не нашел у них на сайте страницы с описанием S3TC и утилитами, которая раньше у них точно была. У меня утилиты остались только в урезанном виде с минимальным набором файлов. Но я нашел полный у Reactor Critical, спасибо им за это.

Для конвертации из/в 16- и 32-битные форматы Targa с квантованием и различными способами дизеринга применялся старый, но довольно удобный просмотрщик графических изображений для DOS Sea 1.3. Он обеспечивает приличное качество дизеринга для 2 методов.

При рассмотрении были взяты два набора текстур:

1) Выборка из текстур демоверсии Quake 3 Arena 1.11, в разных форматах — JPEG и Targa, в количестве 10 штук. Взяты различные типы текстур: с плавными переходами цветовых оттенков, обычные текстуры стен, пола, по одной из текстур неба и моделей персонажей.

Список оригинальных названий и путей:

pak0.pk3\textures\gothic_block\blocks15.jpg
pak0.pk3\textures\gothic_floor\blocks17floor3.jpg
pak0.pk3\textures\skies\inteldimclouds.jpg
pak0.pk3\textures\liquids\kc_fogcloud3.jpg
pak0.pk3\textures\base_wall\patch10_beatup2.jpg
pak0.pk3\textures\gothic_floor\q1metal7_99.jpg
pak0.pk3\gfx\misc\teleportEffect2.jpg
pak0.pk3\models\mapobjects\baph\baphomet_gold.tga
pak0.pk3\textures\skin\chapthroatooz.tga
pak0.pk3\models\players\major\daemia.tga

Ради уменьшения объемов статьи, для визуального сравнения использованы только 3 текстуры: inteldimclouds.tga, teleportEffect2.tga, chapthroatooz.tga
На них хорошо видны недостатки сжатия.

2) Набор из 10 тестовых текстур, собранных специально для определения слабых мест существующего текстурного сжатия. Эти текстуры представляют собой нетипичные или не совсем типичные для игр фрагменты текстур. Например, изображения с очень большим количеством цветов, с плавными и резкими цветовыми переходами, с хаотично разбросанными по площади точками различных цветов. Как показали предварительные тесты и реальные игры (Q3), именно в некоторых из этих условий сжатие показывает себя хуже всего. Еще раз повторюсь, этот набор призван лишь показать недостатки рассматриваемых технологий, он не отражает текущего и будущего состояния текстурирования в играх.

Для визуального сравнения также были отобраны только 3 текстуры: topsmap.tga, reference.tga, abstrwav.tga

Текстура pixtest.tga была вне конкурса, так как она абсолютно не похожа на существующие текстуры. Она использовалась, как самый оригинальный и тяжелый случай.

Следует заметить, что все текстуры имеют одинаковый размер 256х256, для облегчения тестирования и более точных результатов при использованием числового представления. Конечно, технологии сжатия предназначены, прежде всего, для сжатия больших текстур, но для удобства и уменьшения объема использовались именно 256х256 текстуры, в том числе и как наиболее распространенные на данный момент.

Все текстуры перед тестированием конвертировались в 32-битный Targa формат с альфа-каналом, так как других форматов утилиты от 3dfx не понимают. Из текстур с изначальным присутствием альфа-канала, этот канал принудительно убирался для обеспечения равных условий для сравнения 16-битных текстур и текстур, сжатых S3TC и FXT1.

Для сравнения взяты 16-битные текстуры, полученные путем квантования (уменьшения количества цветов) оригиналов до 16 бит с применением двух методов дизеринга и без него. Для визуального сравнения были взяты только 16-битные текстуры с floyd-steinberg dithering, как дающие наилучшие среди 16-битных изображений результаты. Учтем, однако, что в играх, как правило, используется квантование без дизеринга или ordered дизеринг. Поэтому выбранное качество 16-битных текстур — максимально возможное.

Позже эти текстуры переводились обратно в 32-битный формат.

Применение утилит сжатия:

• FXT1 Сжатие
  encode image.tga image.fxt
• FXT1 Распаковка
  decode image.fxt image.tga
• S3TC Сжатие нескольких изображений
  s3tc *.tga
• S3TC Распаковка
  Распаковывать обратно пришлось по очереди через GUI меню, там все легко и понятно — загрузил сжатое, записал в формате Targa.
  Так как утилита записывает 24-битные Targa файлы, то пришлось конвертировать их в 32-битные для численного сравнения.

Качество исходных и полученных изображений сравнивались с помощью программы, которая входит в состав утилит от 3dfx:

• isub –v image.tga image_fxt.tga difference.tga

В результате выполнения difference.tga — файл, показывающий различия входных файлов и некоторая информация о том же самом. Нас интересует значение Root Mean Square (RMS), показывающее среднеквадратическую ошибку. Это значение используется как показатель качества сжатия изображений с потерей информации. Чем меньше показатель — тем лучше качество сжатия. Вообще-то, в выходных данных программы много других интересных и полезных цифр: отдельно по цветовым каналам (RGB), различные суммы и т.д., но их слишком много и для нашего рассмотрения достаточно одного RMS.

Только для визуального сравнения из середины каждого полученного изображения выбранных 6 текстур вырезался кусок 128х128 и его масштаб увеличивался вдвое, т.е. до тех же 256х256 и сжимался в JPEG с качеством 85. Масштабирование применено, чтобы хорошо было видно все недостатки. Чтобы увидеть эти картинки с максимальным качеством, скачайте этот самораспаковывающийся архив (около 600Кб).

Скорость сжатия и распаковки

В сравнении по скорости при помощи чисто теоретических методов особого смысла нет, поэтому этот раздел будет коротким.
Скорость сжатия зависит от многих факторов (оптимизации кода, метода компрессии) и сильно отличается для разных методов. Сжимать текстуры разработчикам придется не часто, если в игре используются изначально сжатые текстуры, поэтому этот параметр не столь критичен. Например, для сложных (мало повторяющихся пикселей) текстур 256х256х32 S3TC справлялась со сжатием примерно за пару секунд, то детище 3dfx делало то же самое примерно за 50-60 секунд на тестовом компьютере. И это на такую, в общем-то, небольшую текстурку! Я понимаю, сжатие у 3dfx более прогрессивное, выбирает формат из нескольких возможных и все такое, но полученная низкая скорость говорит о том, что коду сжатия FXT1 необходима большая работа по оптимизации скорости. Теперь представьте себе игру, которая использует автокомпрессию текстур FXT1 :).

Про скорость декомпрессии по утилитам сказать что-то определенное сложно: на тестовом компьютере текстуры "на глазок" разжимались достаточно быстро. Главное, чтобы приемлемая скорость была на конкретной реализации железа и драйверов, ведь там работа нужна куда быстрее, чем для этих утилит. А там все нормально, при взгляде на реальные приложения (игры) видно, что у всех производителей, встроивших декомпрессию текстур в железо, со скоростью все в порядке — из-за уменьшения объема текстур скорость в результате сжатия возрастает по сравнению с несжатыми текстурами. Например, у видеокарт NVIDIA скорость возрастает достаточно сильно (до 15-20%) в сложно текстурированных играх (тот же Quake 3 в режимах с максимальной детализацией текстур и 32-битным цветом в высоких разрешениях).

Степень сжатия текстур

Расскажу сначала немного про виды сжатия по рабоче-крестьянски, может кому-нибудь полезно будет :). Сжатие бывает без потери информации (LZW, Huffman и другие разновидности, сочетания и методы, которые используются в огромном числе архиваторов, GIF и PNG графических форматах) и с ее потерей (JPEG, MPEG, современные аудиокодеки).

Обе рассматриваемые технологии являются как раз сжатием с потерями, смысл в том, что потери должны быть незначительны и не сильно заметны среднестатистическому глазу. Например, JPEG фотография с качеством выше 85 при разрешении 800x600 и выше "на среднестатистический глазок" на 15" мониторе практически не отличается от оригинала. Но всегда есть определенные задачи и/или люди, которых что-либо мало-мальски неполноценное не устраивает, будь то звук, изображение, или еще что-то.

Бояться, что при приближении к стенке с нанесенной сжатой текстурой огрехи изображения будут сильно видны, не надо, так как при хорошей реализации сжатия/расжатия и при применении больших текстур на место одного тексела текстуры без сжатия придут несколько (4-8) пожатых, что должно только увеличить качество изображения. В общем, хуже уже не будет :). Я рассматриваю случай, когда при использовании сжатия детализация текстур увеличена, при одинаковом размере текстур артефакты сжатия могут быть видны.

Общие принципы компрессии у рассматриваемых технологий схожи, и я не буду их здесь затрагивать, кому надо, могут посмотреть исходники FXT1, которые распространяются вместе с утилитами. Степень сжатия текстур постоянна: у FXT1 это 8-и кратное сжатие текстуры с альфа-каналом, а у S3TC 4-х кратное с альфа и 6-и без альфа-канала или с простым альфа-каналом. Например, 256x256x32 текстура с альфа-каналом ужимается с 256 Кбайт до 32-х при FXT1 и до 64 с S3TC. Другими словами, если S3TC сжимает в 4 раза, то сжатие 3dfx еще в 2 раза уменьшает размеры 32-битной текстуры в памяти!

Со степенью сжатия всё ясно — победила более свежая технология от дедушки игрового 3D железа для PC — 3dfx. Но не будем торопиться, посмотрим, как обстоят дела с качеством.

Качество компрессии — числовое представление

Вот мы и добрались до самого интересного — качества. Вы помните, какое значение мы выбрали для определения качества сжатия? Правильно, RMS. Для того чтобы узнать его чувствительность к огрехам изображения, даны числа для этих же текстур, сжатых с помощью компрессии JPEG с качеством 85, а затем переведенные обратно в Targa. Если кто-то давно или вообще JPEG компрессию в глаза не видел, то можно взять какую-нибудь картинку (лучше текстуру), сжать ее любым редактором и посмотреть. Если интересуют размеры получившихся JPEG’ов, то они были от 5 до 30 Кбайт, что гораздо меньше 32 Кбайт у FXT1 и тем более 42 Кбайт у S3TC, но качество хуже, да и к теме это не совсем относится (сжатие, подобное JPEG, слабо подходит для размещения сжатых текстур в видеопамяти в силу некоторых обстоятельств — скорость распаковки, неудобство модификации текстуры в видеопамяти и др.), поэтому продолжим.

Число FXT1/S3TC показывает, на сколько процентов хуже число RMS при использовании FXT1 по сравнению с S3TC.

S3TC справилась с качественным испытанием лучше, чем FXT1, но обе опередили 16-битные форматы без дизеринга и с упорядоченным дизерингом и слегка отстали от 16-бит с floyd-steinberg дизерингом.

Интересный факт — FXT1 победил S3TC только в двух случаях (kc_fogcloud3.tga и topsmap.tga), но, опять немного забегая вперед, скажу, что визуальное качество сжатия S3TC все равно лучше! Вот что значит оптимизация FXT1 под показатель RMS.

К сожалению, картинки в несжатом 32-бит формате невозможно привести из-за их огромных размеров, а на них видны более точные потери качества.

По этим картинкам можно увидеть потери при сжатии или квантовании.

chapthroatooz.tga

32-бит	16-бит с floyd-steinberg dithering
S3TC	FXT1

Это одна из текстур, где FXT1 имеет вполне сносное качество. Подобных текстур в играх — большинство, но есть и другие. Следующие примеры как раз из таких.

inteldimclouds.tga

32-бит	16-бит с floyd-steinberg dithering
S3TC	FXT1

На 16-битной текстуре видна сильная сеточка, но ее качество вполне сносно для 16-бит. При FXT1 довольно сильный бандинг, а вот у S3TC дела получше.

teleportEffect2.tga

32-бит	16-бит с floyd-steinberg dithering
S3TC	FXT1

Для 16-бит текстура очень хорошо выдержала испытание, а FXT1 опять испытывает большие трудности с градиентами, качество S3TC посередине, но ближе к 16-бит. Посмотрим, что будет с тестовыми изображениями. Пока отметим отставание FXT1.

abstrwav.tga

32-бит	16-бит с floyd-steinberg dithering
S3TC	FXT1

Ну началось — если качество 16-бит очень близко к 32-битной текстуре, то у обоих форматов сжатия сходные недостатки — площади с близкими цветами превратились в квадратные куски одного цвета. У FXT1 качество опять заметно хуже, чем у S3TC. Я даже перепроверил, сначала показалось что перемудрил с форматами. Странно, как это он смог так близко держаться к конкурентам по показателю RMS.

reference.tga

32-бит	16-бит с floyd-steinberg dithering
S3TC	FXT1

У 16-бит — просто сеть. Качество S3TC лучше, бандинг едва заметен. У FXT1 проблемы гораздо заметней — текстура вся, как будто в квадратиках.

topsmap.tga

32-бит	16-бит с floyd-steinberg dithering
S3TC	FXT1

Очень интересно, каким образом по показателю качества FXT1 победил S3TC на этом изображении? На вид сжатая FXT1 текстура гораздо хуже. Видна некоторая зеленоватость картинки у S3TC, возможно именно из-за этого он проиграл своему сопернику при сжатии данной градиентной текстуры. Ведь RMS учитывает сумму различий цветов. Но, в любом случае, на вид FXT1 хуже S3TC. Видать, 3dfx'овцы оптимизировали свой алгоритм исключительно по показателю среднеквадратической ошибки. Чей подход лучше — решать вам, но мне больше нравится сжатие от S3.

И напоследок, изображение, не вошедшее в основную группу. Оно сгенерировано искусственно и очень сильно отличается от всего обычно применяемого в играх. Но все равно интересно, как обозреваемые справятся с неординарным.

pixtest.tga

32-бит	16-бит с floyd-steinberg dithering
S3TC	FXT1

В этом случае победитель явный — 16-битная текстура. А среди текстурных технологий слегка выигрывает FXT1, но выигрыш неоднозначен — в случае FXT1 слишком много сиреневого/розового, а у конкурента картинка зеленоватая (опять зеленый!).

Вывод по визуальному сравнению:
16-бит — хорошо во многих случаях, но почти всегда заметна сетка, плохая передача плавных градиентов.
S3TC — сносное качество во всех случаях кроме последнего, лучшая передача градиентов.
FXT1 — явно проигрывает остальным, плохая передача плавных переходов, достаточно сильный бандинг, заметное ухудшение детализации.

Далее идут картинки, полученные как результат обработки изображений при помощи утилиты isub.exe и обработанные фильтром strong edge detection для того, чтобы хоть что-то было видно. Я старался сделать JPEG'и покачественнее и хотя их нельзя сравнить с оригиналами, я думаю для того, чтобы понять, что к чему, этого вполне достаточно.

Советую посильнее подкрутить яркость на мониторе, чтобы увидеть все недостатки. И не спрашивайте меня, почему картинка у 32-бит полностью черная. Догадайтесь сами :).

chapthroatooz.tga

32-бит	16-бит с floyd-steinberg dithering
S3TC	FXT1

Похоже, что в этом случае лучше справилась 16-битная текстура. Среди остальных — явная победа S3TC, ясно видно, что шума больше у FXT1.

inteldimclouds.tga

32-бит	16-бит с floyd-steinberg dithering
S3TC	FXT1

Уже интереснее — в то время как на 16 битах сильные разводы, на S3TC и FXT1 почти ничего не видно. Сначала я подумал, что что-то напутал, но потом, присмотревшись, увидел таки у FXT1 некоторые недостатки, заметил их и у сжатия от S3.

teleportEffect2.tga

32-бит	16-бит с floyd-steinberg dithering
S3TC	FXT1

На вид хуже всех картинка 16-битного дизеринга. S3TC выигрывает у FXT1 процентов 20, а то и больше.

abstrwav.tga

32-бит	16-бит с floyd-steinberg dithering
S3TC	FXT1

Один из немного неожиданных провалов текстурного сжатия: Hi-Color значительно лучше смотрится. FXT1 опять в самом плохом положении.

reference.tga

32-бит	16-бит с floyd-steinberg dithering
S3TC	FXT1

Вот и реванш. Сжатие S3 показало себя с хорошей стороны, выиграв этот раунд у 16-битной текстуры. FXT1 от опять ощутимо отстало от первого, все же выиграв у второго. Еще одно подтверждение достаточно хорошей работы S3 с градиентами.

topsmap.tga

32-бит	16-бит с floyd-steinberg dithering
S3TC	FXT1

16-бит вне конкуренции — проиграл всем остальным.

И в этом сравнении FXT1 хуже S3TC применительно к данной текстуре. У меня уже возникает некоторое сомнение в правильности выбора числового показателя качества. Но не зря же я сравниваю и визуальные отличия. Глаз человеческий не всегда подчиняется математическим формулам :).

И, наконец, не вошедшее в конкурс тестовое изображение.

topsmap.tga

32-бит	16-бит с floyd-steinberg dithering
S3TC	FXT1

Вот и объяснение плохого показателя у S3TC. Какое красивенькое изображение :). Почему здесь много розового цвета, спросите вы? Очень просто — это значит у S3TC разная точность в передаче цветов. Для зеленого она больше. А у FXT1 довольно равномерные потери всех цветов, но тоже большие. Тут победитель был известен заранее — 16-битная текстура, у которой отсутствуют ограничения, которые есть у обоих конкурентов — малое количество возможных цветов в каждом блоке размером 4х4 пиксела.

Из приведенных картинок видно, что форматы сжатия у соперников очень близки, но отличаются по точности. S3TC справилась с качественным испытанием лучше, чем FXT1, этот метод опередил 16-битный формат, а FXT1 был близко к их лучшему представителю.

У соперников разные потери, а зависимости примерно одинаковые. Хуже всего дела обстоят с текстурами, у которых есть небольшие площади с плавными переходами цветов, после обработки они становятся одинаковым цветом, появляется подобие бандинга, только квадратно-прямоугольного. А с текстурами земли, стен, камней, кирпичей, дверей, окон и другими, чем несказанно богаты 3D игры, дела обстоят гораздо лучше — различия намного менее заметны (например, самая первая сравниваемая текстура).

Вопросы и ответы

1) S3TC уже получил большое распространение, FXT1 также был давно объявлен. Зачем нужен этот обзор вообще?

Ответ прост — я до сих пор не видел качественного (в обоих смыслах) сравнения этих двух технологий, тем более на русском языке. Да и этот обзор уходит немного шире — я постарался показать реальные достоинства и недостатки сравниваемых технологий, а не тот PR-овский полубред, который все читали в разных переводах с английского. Например у 3dfx в пресс-релизе сказано, что их технология имеет лучшее качество, чем у конкурентов (ясное дело, кто имеется в виду). Вот я и попытался посмотреть трезво и со стороны. Также необходимо было качественное сравнение S3TC/FXT1 с 16-битными текстурами. Я надеюсь, что показал достоинства и недостатки обеих сторон.

2) А зачем тогда вообще использовать сжатые текстуры, если они по качеству бывают хуже 16-битных?

Ответ: Надо помнить такой параметр, как размер текстуры в памяти, ведь размер, занимаемый сжатой S3TC/FXT1 текстурой в 3-4 раза меньше, чем 16-битной. Так что смысл в использовании текстурного сжатия в любом случае есть, надо лишь умело им распорядиться. Кроме того, в данном случае (особенно в визуальном сравнении) я рассматривал несколько текстур, самых неблагоприятных для сжатия, подобного S3TC/FXT1. Эти текстуры — исключение, основные же текстуры, например стены/пол/потолок и т.д. выглядят при сжатии лучше, чем 16-битные. Но вообще, в играх необходимо предусматривать текстуры, которые нельзя сжимать, т.е. надо, чтобы они были в определенном формате. Карты освещения низкого разрешения — один из таких примеров. Это хорошо заметно в Quake 3 Arena при использовании сжатия.

3) Почему при исследовании как один из конкурентов использован FXT1, который нигде сейчас не применяется?

Ответ: Пока, кроме S3TC, других распространенных технологий не существует. Но надо же её с чем-то сравнивать, учитывая еще и то, что технология от 3dfx более новая, и должна быть совершеннее.

Заключение

При использовании современных методов компрессии текстур, конечный результат в основном получается качественнее 16-битных текстур или примерно такой же, в то же время занимающий меньше места в видеопамяти. Качество S3TC сжатых текстур близко к качеству 32-битных несжатых текстур, за исключением некоторых особо неблагоприятных случаев (текстуры неба, карты освещения и т.д.). В таких случаях необходимо ограничивать сжатие таких изображений или, что еще лучше, давать возможность выбирать формат текстур пользователю, пусть он сам выбирает между скоростью и качеством. Так уже сделано в технологическом тесте игры Serious Sam Test — там пользователь может выбирать форматы текстур отдельно для стен/потолков/пола, моделей игрока/монстров, карт освещения и др. Выбор достаточно широк — 16-бит с дизерингом (несколько степеней)/без него, 32-бит, S3TC.

S3TC технология появилась гораздо раньше соперницы, этой технологией уже пользуются почти все производители графических чипов. Она обеспечивает очень хорошее качество сжатых изображений, за счет их большего размера, чем у конкурента от 3dfx. По соотношению (степень сжатия/качество) я считаю эту технологию пока лучшей среди существующих. Ее поддержка уже есть и в DirectX (DXTC), это также большой плюс.

Характерные особенности S3TC:
• Хорошее качество — бандинг на низком уровне
• Приемлемая степень сжатия
• Неплохая скорость компрессии/декопрессии
• Отличная поддержка со стороны производителей видеочипов
• Хорошая поддержка разработчиков игр и приложений
• Необходимость лицензирования производителями видеочипов при использовании технологиии в OpenGL

FXT1 использует более агрессивное сжатие, с большей потерей качества по сравнению с S3TC. Этот метод еще больше снижает размер текстур. Пока кто-нибудь не придумает еще более совершенную технологию, лучшие результаты по степени сжатия получатся при использовании FXT1. Но качество в некоторых случаях получается совершенно неприемлемое. Также большим недостатком является скорость компрессии, поэтому разработчикам технологии необходимо оптимизировать код сжатия, чтобы в играх, где текстуры будут сжиматься на лету (как в Quake 3) скорость была достаточной для того, чтобы играть, а не ждать загрузок уровней. Девелоперам игр при использовании предварительно сжатых текстур придется много времени потратить на сжатие текстур. Но главным является вопрос, увидим ли мы вообще когда-нибудь сжатие FXT1 в реальных играх? Я считаю, что нет. S3TC уже получил достаточно широкое распространение, и я не вижу особых причин разработчикам переходить на другие, малоиспользуемые и менее качественные методы сжатия, пусть и с большей степенью сжатия. Еще один плюс в том, что FXT1 открыта, но ей пока это не сильно помогло.

Характерные особенности FXT1:
• Посредственное качество — заметный бандинг на градиентных текстурах и низкая детализация на обычных
• Высокая степень сжатия
• Открытость технологии
• Низкая скорость компрессии
• Плохая поддержка производителей видеочипов
• Никакая поддержка разработчиков

Теперь о сжатии вообще. Оно полностью себя оправдало, при уменьшении необходимой видеопамяти можно увеличить детализацию текстурирования. Не этого ли нам всем надо? Осталось только разработчикам начать повсеместно и грамотно использовать сжатие текстур S3TC/DXTC и, как мне кажется, технологии сжатия получат толчок к своему дальнейшему развитию.

В заключение скажу, что я хотел бы видеть в дальнейших технологиях/играх: несколько типов сжатия с разными коэффициентами (например, от 1:2 до 1:8) и, соответственно, разным качеством. Хорошо, если текстуры были бы изначально не сжаты, а пользователь сам выбирал бы метод сжатия для каждого типа текстур (основные, текстуры моделей, небо, карты освещения, карты среды и т.д.). Нужно также разделение сжатия и по размеру текстур, например, запретить сжатие текстур освещения размером, меньше 64х64 (это хорошо бы тоже доверить пользователю).