Steam Community :: Guide :: Спреи: VTF spray texture guide

Однобітний прозорість в форматі стиснення DXT1A в VTF

[New!] На початку 2017 го, нарешті, знайшлося застосування DXT1A! Ура!

См.сразу наступний розділ: «DXT1A 1024x1020»

Яка користь від DXT1A? (Застаріло)

Формат дозволяє заощадити трохи відеопам'яті; в деяких випадках за рахунок цього можна впихнути в спрей картинку більшого дозволу (512х512 -> 1024x512). В анімації, аналогічний простому DXT1, але дозволяє використовувати прозорість, що облагороджує картинку; наприклад, можна зробити, щоб кадр відео виглядав як прямокутник, а не квадрат.

Отже, що ми маємо на сьогоднішній день:

+ DXT1A на статичних картинках таки працює і його легко отримати.
+ DXT1A в анімації теж працює, але отримати його складніше, потрібні незвичайні маніпуляції з файлами.
- DXT1A на сервері, в режимі деколей / оверлеїв чомусь так і не запрацював, і дуже шкода, я покладав на нього найбільші надії. ((

Як отримати статичну картинку?

Беремо текстуру, наприклад, у форматі tga. Скармливаем її утиліті "crunch: Advanced DXTn Texture Compressor", з такими параметрами: "crunch.exe / DXT1A / mipFilter box / fileformat dds -file наш_файл.tga". На виході отримуємо .dds, який конверт в .vtf за допомогою VPKTool. (Сумно, але у "Кранч" досить погане якість картинки на виході). Після цього розкриваємо готовий .vtf в VTFEdit, і доставляємо потрібні прапори, а потім Перезаписуємо .vtf.

Як отримати анімацію?

Сам поки не робив, але ось добрі люди пишуть, як: http://source.gamebanana.com/tuts/11009 ( «DXT With One Bit Alpha Animated Spray»).
Досить гнітюче виглядає вимога використовувати hex-редактор для створення анімації. ;)

Стогін з приводу недосконалості VTFEdit

Насправді «стогони» можна звести до одного простого твердження: коли розробка утиліти занедбана, а утилітою все ще користуються, ну чому б не відкрити вихідні? Це вирішило б масу проблем.
Отже. Кривий VTFEdit не вказує зведеним прапор "one bit alpha", а мав би, однак - альфу-то на зображенні він бачить, і керувати нею дозволяє (Ctrl-M). Ех, от якби VTFEdit розумів, що можна розкрити DDS-текстуру (імпорт - як окремих картинок для анімації), але обжимати її в DXT заново вже не потрібно, і міпмапи теж заново генерувати ні до чого - можна було б легко і анімацію влаштувати в форматі DXT1A, і міпмами генерувати найвищої якості.

Чому Crunch, а не nVidia Texture Tools?

утиліту " crunch [Code.google.com] "мені довелося використовувати, тому що звичний багатьом розробникам" nVidia Texture Tools for Photoshop "видавав дикі баги на прозорості в форматі dxt1a, причому, якщо включити режим" запис dxt без оптимізації "- баги пропадали, але якість картинки падало нижче плінтуса. Ще - цікавий побічний ефект використання crunch'а - здається, його фільтри роблять мімпами краще, ніж VTFEdit. до речі, за посиланням вище на GameBanana, тамтешні бійці визнають наявність бага в плагінах і розповідають, як його обійти.

DXT1A не такий корисний, як багатьом здається. (Застаріло!)

DXT1A слід використовувати тільки, якщо анімація не влазить; або для збільшення дозволу уздовж однієї зі сторін картинки, в статиці, якщо скажемо, невеликий текст не читається. Якщо ж все і так працює ... При простій заміні стиснення DXT3 -> DXT1A ми бачимо, що розмір нашого файлу із зображенням зменшився з 349 Кб до 176 Кб; але реально це нічого не дасть, тому що, як клієнт, так і сервер TF2 стискають ці зображення при передачі; майже порожній альфа канал в будь-якому випадку не дасть виграшу навіть в швидкості завантаження (виграш стисненого файлу dxt1a в порівнянні з dxt3 / dxt5 всього лише 8..10%).
Приклад. Оцінимо читання тексту в стандартній зображенні 512х512 (ліворуч) проти 1024х512 в форматі DXT1A (праворуч), клікніть для збільшення:
Попередження: див.вище про multicore rendering, спреї 1024х512 (будь-які нерівносторонні) можуть бути неправильно показані на деяких комп'ютерах, що також додає безглуздості їх створення без крайньої на те необхідності.

Як влаштований DXT1A?

Влаштований цей формат текстур точно так же, як DXT1, але є один нюанс: якщо в DXT3 / 5 збережені як би дві окремі площині зображення - окремо альфа-канал і окремо RGB, то в DXT1 існує тільки площину RGB, і нічого більше. Окей, запитаєте ви, а як же вони примудрилися запхати в RGB інформацію про прозорість, в такому випадку? Це тим більш загадково, враховуючи, що ми точно знаємо, як зберігається інформація в площині кольору - картинка розбивається на квадратики 4х4 пікселя, і під кожен такий квадратик виділяється строго 8 байт: по два байта на початковий і кінцевий кольору, і по 2 біти " розподілу "на кожну з 16 точок (ще 4 байта). Жодного зайвого Битик там немає! Ні. На перший погляд. ;) Слідкуйте за руками, приклад: припустимо, початковий колір у нас білий, а кінцевий чорний. І перша ж точка, яку нам треба закодувати, чорного кольору. Так ось, ми це можемо зробити двома способами: оголосити початковий колір білим, кінцевий чорним, а заповнювач (колір пікселя, з палітри 4 кольорів (початковий, кінцевий, і два проміжні, середні між ними)) вказати 11 (біти). Або навпаки, початковий колір буде чорним, а кінцевий білий, а заповнювач тоді буде 00 (двійкове). Підсумкова картинка від цього не зміниться. Але зате, у нас виникає один додатковий біт для квадрата 4х4 - порядок кольорів. І дійсно, розробники з S3 дотепно вирішили, що якщо оголошений формат текстури DXT1A, то, грубо кажучи, якщо початковий колір> кінцевого (кольори - всього лише цифри, до кінці-то кінців), то в цьому квадратику прозорості немає, а в іншому випадку - є. (Насправді там хитріше умова, ніж просто більше-менше). Якщо виявлена ​​прозорість, то в квадратику вже не можуть використовуватися 4 кольори, використовується тільки три, а "кінцевий колір" оголошується прозорим, і не промальовується. На жаль, завдяки такому незвичайному рішенням, на кордоні прозорості можуть з'являтися додаткові артефакти, тому що, колірний простір в цих місцях реально вже, ніж у DXT3 або DXT5.