Найкращий (найпопулярніший?) Формат зображення для текстурування [закрито]

Гаразд, тому я використовую C ++ з OpenGL, і я збираюся створити завантажувач для завантаження текстур для моєї 3D-гри. (Але текстури - 2D). Я хочу варіант прозорості, навіть якщо я вирішу не використовувати його. Мені потрібна гідна якість, хоча вона не повинна бути першокласною. Що ви пропонуєте для формату (PNG, TGA тощо). Також, можливо, зробіть це щось, для чого легко створити завантажувач (я не збираюся використовувати вже створений.) А також, якщо у вас є будь-які посилання / поради, щоб допомогти з завантажувачем, це буде вдячно.

Я не розумію, чому ви не хочете використовувати позашляховий навантажувач. Наприклад, PNG - це хороший вибір формату, але складний для того, щоб написати завантажувач загального призначення для (і, мабуть, не варто докладати зусиль, щоб написати той, який завантажує лише певний підмножина форматів PNG, який вам цікавий).

Зважаючи на дещо незвичну вимогу, TGA - це, мабуть, найкраща ставка. TGA 2.0 має альфа-канал і порівняно простий з PNG.

Формат текстури зображення також є вибором продуктивності. Я рекомендую вам максимально використовувати стислі текстури. На мобільних платформах це може значно покращити продуктивність (40% або навіть більше), використання пам'яті та завантаження часу.

Розглянемо текстуру 1024 * 1024:

• RGB або RGBA (16bit): 2Mo (.5s для завантаження SGS)
• RGBA (32 біт): 4Mo (1 секунда для завантаження на SGS)
• PVRT (4bpp): 512ko (.125s для завантаження на SGS)
• ETC1 + Alpha: 1,5Mo (.4 для завантаження на SGS)

У наших іграх у нас є активи (текстури) у багатьох форматах:

• Формат DDS для текстур DXTC (Платформи настільних ПК: OS X, Linux, Windows і Tegra)
• Формат DDS для текстур ATC (графічні процесори Andreno)
• Формат PVR для формату PVRT (графічні процесори PowerVR)
• Формат PKM для текстури ETC1 (всі сумісні пристрої OGLES 2.0)

Нарешті, ми використовуємо необроблений формат для сумісності, але це для сумісності або елементів графічного інтерфейсу

• Формат PNG для сирого текстури. Це для текстур RGBA 16, 24 або 32 біт (ми використовуємо ліцензований навантажувач MIT). Це нестиснуті текстури.

Текстури ETC1 не мають альфа-каналу, тому ми використовуємо спеціальний шейдер з двома текстурами (rgb текстури та альфа-текстури). Стислий формат дуже легко завантажувати (100 або 200 локальних).

На робочому столі DXTC (S3TC) присутній на багатьох картах. Отже, ви повинні використовувати це.

Стислі текстури

Про

• Поліпшення текстури покращено
• Завантаження текстури (4 рази або більше)
• Легкий у завантаженні

Кон

• Не підтримується на всіх платформах
• артефакти

Текстури - це колекції одного або декількох зображень. Це означає, що текстура може бути представлена ​​TGA або PNG, але жоден формат не здатний представляти всі можливі особливості текстур. Чому?

Тому що кожен може вмістити лише одне зображення. Міп-карти немає. 3D-текстури неможливі. Немає текстур масиву. Без кубічних карт Кожен із цих файлів - це лише одне двовимірне зображення. Вони можуть бути частиною текстури, але якщо ви не використовуєте міпографічні карти (і настійно не рекомендую використовувати мипмапи, якщо у вас немає конкретних потреб), один файл зображення у цих форматах не може бути текстурою.

Вони є прекрасними форматами зображень, але вони мають погані формати текстури .

DDS є головним учасником текстурних форматів, оскільки він фактично підтримує потреби текстур. Він підтримує mipmaps та кубічні карти. Він підтримує 3D текстури. DDSv10 підтримує текстури масиву. Ви можете упакувати одну текстуру в DDS таким чином, щоб не вдалося з PNG або TGA.

DDS підтримує нестиснуті та стислі дані текстури. Поки формат стислих текстур є одним із форматів текстур DXT / BC.

ПКМ корисний для упаковки зображень, стиснених ETC1, але, як і у форматі PNG, він не підтримує фактичних особливостей текстури.

Файли PVR здаються мобільним еквівалентом DDS (хоча чому вони не могли просто використовувати DDS, я не знаю). Вони підтримують різні методи стиснення, але їм не вистачає передових функцій DDSv10, таких як текстури масиву, а також підтримка 3D-текстури.

Таким чином, DDS виграє з точки зору всебічної підтримки текстури.

Група Khronos рекомендує формат файлу KTX для зберігання текстур для програм OpenGL та OpenGL ES. Ви можете використовувати libktx для роботи з цим форматом.

Особливості:

• Миттєвий текст OpenGL з файлу KTX
• Декомпресуйте стиснене зображення текстури ETC1, коли апаратне забезпечення не підтримує ETC1.
• Створіть хеш-таблицю пар ключових значень з файлу KTX під час завантаження текстури
• Напишіть файл KTX з масиву вихідних зображень та необов'язкової хеш-таблиці пар ключ-значення.
• Сконструюйте та заповніть хеш-таблицю пар ключових значень.

Схоже, що DDS (DirectDraw Surface) - найпопулярніший вибір текстур на даний момент. Є різні формати пікселів, прозорість і стиснення. Він підтримується у OpenGL через розширення GL_ARB_texture_compression.

Наприклад, є завантажувач OpenGL тут .

Тут є ряд міркувань:

1. Як швидко ви можете отримати текстуру з диска і в системну пам'ять.
2. Як швидко ви можете отримати текстуру з системної пам'яті до графічного процесора (через glTexImage2D у вашому випадку).
3. Скільки місця на диску та пам’яті відео оперативної пам’яті у вашому бюджеті.
4. Продуктивність та якість.

TGA - хороший вибір, оскільки у 24 та 32 бітових нестиснених випадках ви можете прочитати дані за один єдиний фрейд / що завгодно та відправити результат безпосередньо через glTexImage2D без подальшої обробки. Це поганий вибір, оскільки він може мати найбільший розмір файлу, і якщо введення / виведення диска - це вузьке місце, то ваші читання будуть повільними.

PNG - хороший вибір, оскільки він зберігає якість зображень з досить малим розміром файлу. Це поганий вибір, оскільки PNG можуть декомпресувати - якщо це ваше вузьке місце - ну, ви знаєте.

JPG - хороший вибір, оскільки він, як правило, має найменший розмір файлу, і вийде з диска дуже швидко (вдвічі добре, якщо вам потрібно надіслати файл по мережі). Це поганий вибір через проміжні кроки декомпресії програмного забезпечення та втрату якості (хоча ви можете налаштувати налаштування якості, щоб зменшити це). Також немає альфа-каналу.

DDS (або інші стислі формати) - хороший вибір через менший розмір файлу та можливість включення попередньо вбудованого ланцюга mipmap. Якщо це формат, який підтримується в апараті (і DDS підтримується на більшості апаратних засобів споживчого ПК - вже давно), ви отримуєте ту ж перевагу, що і TGA - один фрейд, трохи засунувшись в заголовок, щоб зрозуміти деякі властивості зображення, а потім надсилати дані прямо без проміжних кроків. Стислі текстури також змусять вашу програму працювати швидше і використовувати менше оперативної пам’яті. Вони поганий вибір, оскільки вони використовують стиснення втрат (що іноді може бути справді помітним) і можуть не підтримуватися на всіх апаратних засобах.

Якби це я, я створив би підтримку всіх 4 цих форматів (TGA і DDS досить тривіально писати завантажувачі для, за допомогою JPG та PNG я б використовував бібліотеку зображень), щоб творці вмісту могли вибрати найбільш підходящий формат на на основі текстури.

І звичайно, ви завжди можете використовувати старий 32-бітний BMP, який дуже легко завантажувати (особливо якщо розмір - потужність 2 (насправді кратна 8 байтам IIRC)).

Інакше здається дивним, що вам потрібен лише один формат, jpg справді крутий для приємних тексту реального часу в реальному світі (jpeg робить дивовижі з дисковим простором та (вниз) завантаженням), png для прозорості та привідним 32-бітовим BMP для контрольних текстур. (легко створити за допомогою сценарію або "швидкого та брудного" інструменту).