Najlepszy (najbardziej popularny?) Format obrazu dla teksturowania [zamknięty]

13

Okej, więc używam C ++ z OpenGL i zamierzam stworzyć moduł ładujący do załadowania tekstur do mojej gry 3D. (Ale tekstury są 2D). Chcę opcji przejrzystości, nawet jeśli zdecyduję się jej nie używać. Potrzebuję przyzwoitej jakości, chociaż nie musi to być na najwyższym poziomie. Co sugerujecie dla formatu (PNG, TGA itp.). Może też sprawię, że będzie to łatwe do utworzenia modułu ładującego (nie zamierzam używać już utworzonego modułu ładującego). A także, jeśli masz jakieś linki / porady, które pomogą w ładowaniu, byłoby to mile widziane.

Brandon oubiub
źródło

Odpowiedzi:

15

Nie rozumiem, dlaczego nie chcesz używać gotowego modułu ładującego. Na przykład PNG jest dobrym wyborem dla formatu, ale jest skomplikowane, aby napisać moduł ładujący ogólnego przeznaczenia (i prawdopodobnie nie jest wart wysiłku napisania takiego, który ładuje tylko określony podzbiór formatów PNG, na których Ci zależy).

Biorąc pod uwagę to nieco nietypowe wymaganie, TGA jest prawdopodobnie najlepszym wyborem. TGA 2.0 ma kanał alfa i jest stosunkowo prosty w porównaniu do PNG.


źródło
3
+1 dla TGA, jeśli OP chce napisać własny. Raz napisałem własny moduł ładujący TGA. Tak szybko i bezboleśnie.
Kaczka komunistyczna
4
@Duck: Bezbolesne, o ile wykonujesz proste TGA bez kompresji lub jakiejkolwiek fantazyjnej funkcji. Jeśli chcesz mieć w pełni zgodny moduł ładujący TGA, zauważyłem, że to trochę bolesne. To trochę dziwny format.
ZorbaTHut
1
@Zorba, kompresja dość łatwa. To tylko, czy zależy Ci na rozszerzeniach, czy nie.
deceleratedcaviar
10

Format tekstury obrazu jest również wyborem wydajności. Zalecam, aby w miarę możliwości używać skompresowanych tekstur. Na platformach mobilnych może znacznie poprawić wydajność (40% lub nawet więcej), zużycie pamięci i ładowanie czasu.

Rozważ teksturę 1024 * 1024:

  • RGB lub RGBA (16 bitów): 2Mo (0,5 s, aby załadować SGS)
  • RGBA (32 bity): 4Mo (1 s, aby załadować SGS)
  • PVRT (4 bpp): 512ko (.125s, aby załadować SGS)
  • ETC1 + Alpha: 1,5Mo (.4 s, aby załadować SGS)

W naszych grach mamy zasoby (tekstury) w wielu formatach:

  • Format DDS dla tekstur DXTC (platformy komputerowe: OS X, Linux, Windows i Tegra)
  • Format DDS dla tekstur ATC (procesory graficzne Andreno)
  • Format PVR dla formatu PVRT (procesory graficzne PowerVR)
  • Format PKM dla tekstury ETC1 (wszystkie urządzenia kompatybilne z OGLES 2.0)

Nareszcie używamy surowego formatu dla kompatybilności, ale to dla kompatybilności lub elementów GUI

  • Format PNG dla surowej tekstury. Dotyczy tekstur RGBA 16, 24 lub 32 bity (używamy licencjonowanego modułu ładującego MIT). To nieskompresowane tekstury.

Tekstury ETC1 nie mają kanału alfa, dlatego używamy specjalnego modułu cieniującego z dwiema teksturami (tekstury rgb i tekstury alfa). Skompresowany format jest bardzo łatwy do załadowania (100 lub 200 loc).

Na komputerze DXTC (S3TC) jest obecny na wielu kartach. Więc powinieneś go użyć.

Skompresowane tekstury

Zawodowiec

  • Poprawiono wypełnianie tekstur
  • Ładowanie tekstury (4x lub więcej)
  • Łatwy do załadowania

Kon

  • Nie obsługiwane na wszystkich platformach
  • artefakty
Ellis
źródło
6
Istnieje duża różnica między teksturami kompresowanymi na karcie wideo (np. DXTC) a teksturami, które są kompresowane tylko podczas przechowywania i muszą być dekompresowane podczas ładowania (np. PNG). PNG będzie ładować się wolniej niż nieskompresowana tekstura, ponieważ najpierw musi zostać zdekompresowana. Są mniejsze, tak, ale ilość zużywanej pamięci graficznej jest taka sama.
jhocking
8

Tekstury to zbiory jednego lub więcej obrazów. Oznacza to, że teksturę można przedstawić za pomocą TGA lub PNG, ale żaden format nie jest w stanie przedstawić wszystkich możliwych cech tekstur. Dlaczego?

Ponieważ każdy z nich może zawierać tylko jeden obraz. Nie ma mipmap. Tekstury 3D nie są możliwe. Brak tekstur tablic. Brak map sześciennych. Każdy z tych plików to tylko jeden obraz 2D. Mogą być częścią tekstury, ale jeśli nie używasz mipmapowania (i zdecydowanie odradzam nieużywanie mipmap, chyba że masz określone potrzeby), pojedynczy plik obrazu w tych formatach nie może być teksturą.

Są to dobre formaty obrazów, ale tworzą złe formaty tekstur .

DDS jest liderem formatów tekstur, ponieważ w rzeczywistości obsługuje rzeczy, których potrzebują tekstury. Obsługuje mipmapy i cubemapy. Obsługuje tekstury 3D. DDSv10 obsługuje tekstury tablic. Możesz spakować pojedynczą teksturę w DDS w sposób, którego nie można było uzyskać przy pomocy PNG lub TGA.

DDS obsługuje nieskompresowane i skompresowane dane tekstury. Tak długo, jak skompresowany format tekstury jest jednym z formatów tekstur DXT / BC.

PKM jest przydatny do pakowania obrazów skompresowanych ETC1, ale podobnie jak w przypadku PNG, nie obsługuje faktycznych funkcji tekstur.

Pliki PVR wydają się być mobilnym odpowiednikiem DDS (choć nie wiem, dlaczego nie mogli po prostu użyć DDS). Obsługują różne techniki kompresji, ale brakuje im zaawansowanych funkcji DDSv10, takich jak tekstury tablic, a także obsługa tekstur 3D.

Tak więc DDS wygrywa pod względem kompleksowej obsługi tekstur.

Nicol Bolas
źródło
2
Mówiąc wyłącznie o funkcjach, TIFF obsługuje wszystkie funkcje DDS i wiele więcej. Chcesz mieć teksturę z kanałami dalekiej podczerwieni, bliskiej podczerwieni, R, G, B i UV oprócz Alpha? W 64-bitowym zmiennoprzecinkowym IEEE na kanał? Skompresowany przez jeden z wielu algorytmów (w tym JPEG i JPEG2000) odpowiedni dla kanału? Z wieloma obrazami na plik i bogatymi metadanymi dla każdego z nich? Może zrobić to wszystko i wiele więcej. Od pewnego czasu jest to także „natywny” format Photoshopa. A teraz, jeśli chodzi o napisanie modułu ładującego ...
Martin Sojka
Pozwól mi dodać więcej informacji na temat wymogu używania tylko formatu tekstury DXT / BC w kontenerze DDS; wydaje się, że tak nie jest. Widziałem Compressonator używający różnych formatów kompresji i wyjściowych jako .dds dla wszystkich (widzę tę wskazówkę w pomocy wyjściowej podczas wykonywania jej biblioteki cli) i [this] (odpowiedź) na SO, mówiącą, że możesz użyć dowolnego formatu kompresji (ustawiając różne FourCC wtedy sobie poradzimy).
haxpor
1
@haxpor: Możesz wepchnąć cokolwiek chcesz w pliku i nazwać to DDS. Pytanie brzmi: czy aplikacja, która potrafi odczytywać normalne pliki DDS, będzie w stanie odczytać twoją, czy będzie musiała być do tego specjalnie zakodowana? Format DDS określa tylko formaty kompresji DXT / BC (i przypuszczam, że obecnie ASTC). Co się stanie, jeśli użyjesz innego formatu, to między programem, który go pisze, a programem, który go czyta. Ale dotyczy to praktycznie każdego formatu obrazu.
Nicol Bolas,
@NicolBolas Dziękujemy za podsumowanie. Myślę, że to jest to.
haxpor
5

Grupa Khronos zaleca format plików KTX do przechowywania tekstur w aplikacjach OpenGL i OpenGL ES. Możesz używać libktx do pracy z tym formatem.

Cechy:

  • Utwórz teksturę OpenGL z pliku KTX
  • Zdekompresuj skompresowany obraz tekstury ETC1, gdy sprzęt nie obsługuje ETC1.
  • Stwórz tabelę skrótów par klucz-wartość z pliku KTX podczas wczytywania tekstury
  • Napisz plik KTX z tablicy obrazów źródłowych i opcjonalnej tabeli skrótów par klucz-wartość.
  • Zbuduj i wypełnij tabelę skrótów par klucz-wartość.
KindDragon
źródło
3

Wygląda na to, że DDS (DirectDraw Surface) jest obecnie najpopularniejszym wyborem dla tekstur. Ma różne formaty pikseli, przezroczystość i kompresję. Jest obsługiwany w OpenGL poprzez rozszerzenie GL_ARB_texture_compression.

Na przykład jest tutaj moduł ładujący OpenGL .

mrbinary
źródło
Twoja odpowiedź jest nieco myląca. Nie ma sensu mówić, że DDS jest obsługiwany w OpenGL. OpenGL nie obsługuje formatów obrazów.
rdb
3

Istnieje tutaj kilka czynników:

  1. Jak szybko możesz pobrać teksturę z dysku i do pamięci systemowej.
  2. Jak szybko możesz przenieść teksturę z pamięci systemowej do GPU (w twoim przypadku przez glTexImage2D).
  3. Ile miejsca na dysku i pamięci RAM wideo jest w twoim budżecie.
  4. Wydajność i jakość.

TGA jest dobrym wyborem, ponieważ w 24 i 32-bitowych nieskompresowanych przypadkach możesz odczytać dane w jednym fread / cokolwiek i wysłać wynik bezpośrednio przez glTexImage2D bez dalszego przetwarzania. To zły wybór, ponieważ może mieć największy rozmiar pliku, a jeśli dyskowe operacje we / wy stanowią wąskie gardło, odczyty będą powolne.

PNG to dobry wybór, ponieważ zachowuje jakość zdjęć przy stosunkowo niewielkim rozmiarze pliku. To zły wybór, ponieważ pliki PNG mogą ulegać powolnej dekompresji - jeśli to jest twoje wąskie gardło - no wiesz.

JPG to dobry wybór, ponieważ ogólnie ma najmniejszy rozmiar pliku i bardzo szybko schodzi z dysku (podwójnie dobry, jeśli chcesz wysłać plik przez sieć). Jest to zły wybór z powodu pośrednich etapów dekompresji oprogramowania i utraty jakości (chociaż można dostroić ustawienia jakości, aby to złagodzić). Brak kanału alfa.

DDS (lub inne skompresowane formaty) są dobrym wyborem ze względu na mniejszy rozmiar pliku i możliwość dołączenia gotowego łańcucha mipmap. Jeśli jest to format, który jest natywnie obsługiwany sprzętowo (a DDS jest natywnie obsługiwany na większości komputerach konsumenckich - również od dawna), masz taką samą korzyść jak TGA - jeden fread, trochę szturchania w nagłówku, aby dowiedzieć się, niektóre właściwości obrazu, a następnie prześlij dane bezpośrednio, bez pośrednich kroków. Skompresowane tekstury sprawią, że Twój program będzie działał szybciej i zużywa mniej pamięci RAM wideo. Są złym wyborem, ponieważ używają kompresji stratnej (co czasami może być naprawdę zauważalne) i mogą nie być obsługiwane na wszystkich urządzeniach.

Gdybym to był ja, zbudowałbym obsługę wszystkich 4 tych formatów (TGA i DDS są dość trywialne do napisania programów ładujących, z JPG i PNG użyłbym biblioteki obrazów), aby twórcy treści mogli wybrać najbardziej odpowiedni format na na podstawie tekstury.

Maximus Minimus
źródło
1
„DDS jest natywnie obsługiwany na większości komputerach osobistych” DDS jest pojemnikiem dla różnych formatów. Nie przekazujesz pliku DDS do GPU, ale jego zawartość!
Tara,
0

I oczywiście zawsze możesz skorzystać ze starego 32-bitowego BMP, który jest naprawdę łatwy do załadowania (szczególnie jeśli rozmiar to potęga 2 (w rzeczywistości wielokrotność 8 bajtów IIRC)).

W przeciwnym razie wydaje się dziwne, że potrzebujesz tylko jednego formatu, jpg jest naprawdę fajny dla ładnych rzeczywistych tekstur hi res (jpeg robi cuda z przestrzenią dyskową i (w dół) czasami ładowania), png dla przezroczystości i czasami 32-bitowy BMP dla tekstur kontrolnych (łatwe do utworzenia ze skryptu lub „szybkiego i brudnego” narzędzia).

Valmond
źródło