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

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.

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.

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

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.

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ść.

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 .

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.

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).