16-bitowe pół-pływające obrazy HDR jako tekstury (rozproszone / albedo)?

Zastanawiałem się przez chwilę i szukałem odpowiedzi w Google, ale bezskutecznie.

Jeśli wszystkie tekstury są 8-bitowymi obrazami LDR, takimi jak JPEG, nie może to potencjalnie powodować konfliktów z kontrolą ekspozycji / mapowaniem tonów podczas renderowania. To znaczy, jeśli dostosujesz ekspozycję renderowania obrazu, która powinna pokazywać szczegóły w teksturach, których tak naprawdę nie ma, ponieważ zostały one ograniczone przez niski zakres dynamiczny. Czy nie ma więc sensu umieszczanie tekstur jako obrazów HDR, zapisanych jako .exr, w liniowej przestrzeni kolorów z 16-bitowym półpływakiem, aby uzyskać dobrą reprezentację kolorów (32-bitowy „pełny” float może być przesadny?). Wydaje mi się, że aby mieć bardziej szczegółowe i prawidłowe wartości kolorów, mam wpływ na GI i sposób obliczania spadania koloru?

A może po prostu nie jest to konieczne, ponieważ końcowy efekt renderowania, który chcemy, prawdopodobnie będzie podobny do poziomu ekspozycji tekstury, gdy zostanie ona w jakikolwiek sposób sfotografowana? A ponieważ aparat najczęściej fotografuje w 12-14 bitach, musiałbyś wykonać wiele ekspozycji tekstury i wykonać całą tę dodatkową pracę, aby połączyć je wszystkie w jeden HDRI.

Edycja: Aby to wyjaśnić, najbardziej interesuje mnie to z punktu widzenia realistycznego renderowania zdjęć, z rendererami śladów promieni (takich jak mental ray, V-Ray, Arnold itp.) Z pełnymi symulacjami światła i globalnym oświetleniem, a nie dla silniki do gier w czasie rzeczywistym.

W produkcji filmowej prawie nigdy nie używamy 8-bitowych tekstur dla koloru / albedo, z powodu pasmowania itp. (JPEG jest szczególnie problematyczny, ponieważ według specyfikacji jest to raczej sRGB niż wartości liniowe.) Albo używamy „połowy” (16-bitowy zmiennoprzecinkowy) ) lub 16-bitowych wartości całkowitych bez znaku dla tekstur kolorów / albedo.

Tak, w niektórych ekstremalnych przypadkach oświetlenie HDR i mapowanie tonów może ujawnić problemy z paskowaniem w teksturach kolorowych. W takich przypadkach przydatna może być większa głębia bitowa dla tekstur. Jednak z mojego doświadczenia wynika, że ​​większość materiałów i zwykłe sytuacje oświetleniowe nie wykazują tego problemu, a większość tekstur w typowej grze jest dobra w wersji 8-bitowej (lub nawet mniej - gry często używają kompresji BC1, co zmniejsza je do 5 6-5 bitów).

Ludzie używają celów renderowania HDR, ponieważ pojedyncza scena może zawierać bardzo różne wielkości jasności, takie jak ciemny pokój, w którym można zobaczyć przez okno do oświetlonej słońcem części zewnętrznej 10–100 razy jaśniejszej niż pomieszczenie. Jednak tekstury kolorów nie mają tak szerokiego zakresu wielkości. Reprezentują one współczynniki odbicia, które są z natury w zakresie [0, 1], aw praktyce niewiele materiałów codziennego użytku ma współczynnik odbicia mniejszy niż około 2–5%. Tak więc obraz 8-bitowy (z kodowaniem gamma) może zwykle reprezentować rozproszone i lustrzane kolory z wystarczającą precyzją.

To prawda, że ​​połączenie dość ciemnej tekstury z bardzo jasnym oświetleniem lub wyjątkowo prześwietlonym ustawieniem kamery może pokazywać paski w ostatniej klatce, ale byłby to bardziej niezwykły przypadek.

Przypadkiem, w którym prawdopodobnie chcielibyście mieć teksturę HDR, są materiały emisyjne, szczególnie w przypadku neonów i podobnych źródeł światła. Tekstura miałaby zwiększoną wartość, aby była jasnym źródłem światła w grze, więc w takim przypadku 8-bitowy obraz może łatwo pokazać pasy.

Wreszcie, nadal przydatne może być działanie z większą precyzją (np. 16-bitową precyzją), jeśli to możliwe, podczas przechwytywania i tworzenia tekstur, po prostu dlatego, że daje to więcej miejsca na przetwarzanie obrazu bez powodowania problemów z precyzją. Na przykład, jeśli musisz dostosować poziomy lub balans kolorów, tracisz trochę precyzji; które mogą wprowadzić pasmowanie (zwłaszcza jeśli robisz to wiele razy), gdy zaczynasz od 8-bitowego obrazu źródłowego. Źródło 16-bitowe byłoby bardziej odporne na takie problemy. Jednak ostateczna tekstura zastosowana w grze prawdopodobnie nadal byłaby skompresowana do wersji 8-bitowej.

Chciałbym zaprosić czytelników do przeczytania tego artykułu na temat technologii rasteryzacji silnika Quake 2 wyjaśnionego szczegółowo , jeśli mają na to czas.

Jeśli TLDR, proszę zwrócić uwagę na ten obraz:

Widzimy kanał Albedo , to właśnie chcesz zakodować w 16 bitach, jeśli dobrze rozumiem twoje pytanie.
Nie powiem „ jeśli mógłby być zakodowany w 256 kolorach dla gier w przeszłości, dlaczego potrzebowalibyśmy 281474976710656 (to 281 bilionów) w nowych grach? ”, Nawet jeśli chcę, ale to brzmi jak zrzędliwy facet Pixara z W górę. Bardziej konstruktywnie, jeśli zauważysz na tym obrazie, wszystko jest na tym samym poziomie oświetlenia . W szczególności maksymalna możliwa intensywność, która zachowuje pożądane nasycenie. (co oznacza w przestrzeni HSV, V jest maksymalne)

Nacisk jest kluczowy, prawie nie potrzebujemy żadnych bitów, ponieważ albedo i tak nie ma głębokości do zakodowania. Dynamika pochodzi z cieniowania, warto pracować nad f32komponentami w modułach cieniujących i wysyłać je do f16renderowania celów. Ale przechowywanie tekstur albedo f16to nie tylko przesada, to poważny nieuzasadniony świnia wydajności dla naszej cennej przepustowości.