Rozdziały 10 i 11 podały model materiału jako wzory. W produkcji nikt nie wpisuje tych wzorów ręcznie — buduje graf węzłów, który potem musi zadziałać w Arnoldzie, w Karmie, w podglądzie w Houdinim i w przeglądarce USD, dając ten sam wynik. Ten dodatek wyjaśnia, jak to w ogóle możliwe, że jeden opis materiału działa w kilku silnikach naraz.
W rasteryzacji shader fragmentu dostaje wszystkie dane wejściowe naraz i zwraca gotowy kolor. W ray tracerze to nie zadziała — i powód jest ten sam, który przewijał się przez cały Rozdział 15.
Żeby policzyć kolor, trzeba znać L_i, czyli światło przychodzące. Żeby je poznać, trzeba wystrzelić promienie. Żeby wiedzieć, gdzie je wystrzelić, trzeba znać BRDF — bo importance sampling z Dodatku B losuje kierunki proporcjonalnie do niej. Ale BRDF jest wynikiem działania shadera. Shader musiałby więc zwrócić kolor, żeby renderer mógł mu dostarczyć dane, których shader potrzebuje, żeby zwrócić kolor.
Wyjście z tego błędnego koła nazywa się domknięciem. Shader nie liczy koloru — opisuje BRDF i oddaje ten opis rendererowi:
To rozdzielenie ma jeszcze jedną konsekwencję, którą widać w praktyce: shader nie może „podejrzeć” światła i zareagować na nie warunkiem. Próba napisania materiału, który zachowuje się inaczej w cieniu niż w świetle, rozbija się właśnie o tę granicę — i to jest cecha, nie ograniczenie implementacji.
Open Shading Language powstał w Sony Imageworks właśnie po to, żeby pisać domknięcia. Składniowo przypomina C, ale zwraca nie kolor, tylko wyrażenie budowane z wbudowanych domknięć — diffuse, microfacet, emission i kilkunastu innych — które można ze sobą mieszać i ważyć.
Dla artysty technicznego istotne są trzy konsekwencje. Po pierwsze, OSL kompiluje się raz i działa w każdym rendererze, który go obsługuje. Po drugie, węzły w edytorze materiałów to najczęściej właśnie shadery OSL — graf, który klikasz, jest kompilowany do jednego programu. Po trzecie, koszt: rozbudowana sieć węzłów to realny czas liczony przy każdym trafieniu promienia, a nie raz na obiekt.
↓ Dodatek J — ile faktycznie kosztuje sieć shaderówOSL rozwiązuje problem „jak opisać materiał”, ale nie „jak przenieść go z Mayi do Houdiniego bez przepisywania”. Tym zajmuje się MaterialX: to opis grafu węzłów wraz z definicjami, co każdy węzeł znaczy — niezależny od konkretnej aplikacji.
Najważniejszy element z punktu widzenia tej książki to MaterialX Standard Surface: uzgodniony, spisany model powierzchni, którego wejścia to dokładnie parametry z Rozdziału 11 i Dodatku AG — base, specular roughness, metalness, IOR, transmission, subsurface, coat. To nie jest „jeszcze jeden shader”, tylko wspólny mianownik, do którego kilku producentów silników się zobowiązało.
W praktyce oznacza to, że kolumna parametrów, którą stroisz w lookdevie, jest dziś w dużej mierze ta sama niezależnie od silnika — a różnice, na które trafiasz, są różnicami implementacji tego samego modelu, nie różnicami modelu.
Karma używa MaterialX natywnie — graf, który budujesz w Solarisie, jest grafem MaterialX, a nie tłumaczeniem na niego. Arnold i RenderMan obsługują zarówno własne węzły, jak i MaterialX; standard_surface Arnolda i MaterialX Standard Surface to celowo ten sam model o tych samych nazwach wejść. OSL działa w Arnoldzie, RenderManie i Cyclesie.
Praktyczna konsekwencja przy przenoszeniu materiału: rozjazd wyglądu między silnikami przy identycznych wartościach wynika prawie zawsze z rzeczy obok modelu — innej przestrzeni kolorów tekstury (Dodatek E), innych jednostek sceny przy SSS (Dodatek AG) albo innego domyślnego filtra tekstur (Dodatek G) — a nie z samej BRDF.
Blok lookdev zamknięty: materiał opisany, geometria wygenerowana, rozpraszanie podpowierzchniowe policzone. Dodatki AJ–AL zajmują się tym, co dzieje się z gotowym renderem — jak rozdzielić go na warstwy, którymi da się sterować w compingu.