The BRDF you spent twenty-three chapters on doesn't change when the renderer has 16 milliseconds instead of twenty minutes. Almost everything around it does. BRDF, któremu poświęciliśmy dwadzieścia trzy rozdziały, nie zmienia się, kiedy renderer dostaje 16 milisekund zamiast dwudziestu minut. Prawie wszystko dookoła niego — tak.
The frame budget follows straight from the target frame rate, and it is the number every other decision in this part of the book bends around: Budżet klatki wynika wprost z docelowej liczby klatek na sekundę i to on jest liczbą, wokół której zagina się każda inna decyzja w tej części książki:
A production Arnold frame at 3–4k samples per pixel spends somewhere between several minutes and several hours on exactly the same work. The ratio is roughly five to six orders of magnitude, and it is not closed by a faster GPU — it is closed by approximation: fewer rays, reused results between frames, screen-space substitutes for world-space effects, and material models that stop before the last few percent of accuracy. Produkcyjna klatka w Arnoldzie przy 3–4 tysiącach próbek na piksel zajmuje na dokładnie tej samej robocie od kilku minut do kilku godzin. Stosunek to mniej więcej pięć–sześć rzędów wielkości i nie domyka go szybszy GPU — domyka go przybliżenie: mniej promieni, wyniki używane ponownie między klatkami, ekranowe substytuty efektów liczonych w przestrzeni świata i modele materiałów, które zatrzymują się przed ostatnimi kilkoma procentami dokładności.
Most game engines shade deferred: the first pass rasterises geometry and writes each pixel's material properties into a set of screen-sized textures — the G-Buffer (geometry buffer) — and lighting runs afterwards, reading those buffers instead of re-evaluating the shader per light. This is what makes hundreds of lights affordable, and it is also the hard wall the material system runs into. Większość silników gier cieniuje deferred: pierwszy przebieg rasteryzuje geometrię i zapisuje właściwości materiału każdego piksela do zestawu tekstur wielkości ekranu — G-Buffera (bufora geometrii) — a oświetlenie liczy się później, czytając te bufory zamiast liczyć shader raz na światło. To dzięki temu setki świateł stają się osiągalne i to jest też twarda ściana, o którą uderza system materiałów.
The G-Buffer has a fixed layout. Base colour, world normal, roughness, metallic, specular, ambient occlusion, a shading-model identifier and a small number of "custom data" slots — that is roughly the whole vocabulary a deferred pixel gets. In Arnold, by contrast, a shader can carry an arbitrary tree of closures to the integrator; there is no fixed budget of per-pixel numbers, because shading happens at the hit point, not from a buffer. G-Buffer ma stały układ. Kolor bazowy, normalna w przestrzeni świata, roughness, metallic, specular, ambient occlusion, identyfikator modelu cieniowania i niewielka liczba slotów „custom data” — to mniej więcej całe słownictwo, jakie dostaje piksel w deferred. W Arnoldzie dla odmiany shader może przekazać integratorowi dowolne drzewo closure'ów; nie ma stałego budżetu liczb na piksel, bo cieniowanie dzieje się w punkcie trafienia, a nie z bufora.
Two practical consequences follow, and both explain things that surprise lookdev artists arriving from VFX. First, "shading models" in a game engine are a closed list you pick from (default lit, subsurface, cloth, hair, clear coat, …) rather than a stack you build, because each one is a different way of interpreting the same fixed buffer slots. Second, transparency usually leaves the deferred path entirely and is shaded forward, per object — which is exactly why glass, hair and foliage in a game behave like a separate, more restricted material world than everything else. Wynikają z tego dwie praktyczne konsekwencje i obie tłumaczą rzeczy, które zaskakują lookdev artystów przychodzących z VFX. Po pierwsze, „modele cieniowania” w silniku gry to zamknięta lista do wyboru (default lit, subsurface, cloth, hair, clear coat, …), a nie stos, który się buduje — bo każdy z nich to inny sposób interpretacji tych samych, stałych slotów bufora. Po drugie, transparencja zwykle w ogóle opuszcza ścieżkę deferred i jest cieniowana forward, per obiekt — i właśnie dlatego szkło, włosy i listowie w grze zachowują się jak osobny, bardziej ograniczony świat materiałowy niż cała reszta.
Before touching a single engine, it is worth sorting the previous twenty-three chapters into two piles. The left-hand column below transfers essentially unchanged — the same reasoning, the same numbers, sometimes literally the same texture files. The right-hand column is where a realtime engine substitutes something else, and where an artist trained offline will mispredict the result. Zanim dotkniemy jakiegokolwiek silnika, warto posortować poprzednie dwadzieścia trzy rozdziały na dwie kupki. Lewa kolumna poniżej przenosi się w zasadzie bez zmian — to samo rozumowanie, te same liczby, czasem dosłownie te same pliki tekstur. Prawa kolumna to miejsca, w których silnik realtime podstawia coś innego i w których artysta wyszkolony offline źle przewidzi wynik.
| Topic | Transfers 1:1 | Substituted in realtime |
|---|---|---|
| Linear light workflow (Ch. 3) | Yes — engines shade linear too | — |
| Colour vs data textures (Ch. 11) | Yes — same sRGB / raw decision | — |
| Metal/rough, Fresnel (Ch. 13–14) | Yes — same parametrisation | Complex IOR is always the Schlick + edge-tint approximation, never real n + ik |
| Energy conservation (Ch. 15) | Reasoning yes | Multi-scatter GGX compensation is often a fitted curve, not integration |
| Global illumination (Ch. 21) | — | Screen-space or software/hardware ray tracing with a limited bounce count; off-screen light comes from a coarser cache |
| Subsurface (Ch. 16–17) | Look intent yes | Screen-space diffusion profile, not random-walk transport — thin geometry loses its transmission |
| Displacement (Ch. 20) | Height data yes | Mostly parallax/normal detail; true tessellation is budgeted geometry, not free micro-detail |
| Hair and cloth (Ch. 19) | Shading model yes | Cards and strand LODs instead of full curve sets |
| AOVs and debugging (Ch. 23) | Concept yes | Buffer visualisation modes, not arbitrary LPEs |
| Per-material sampling | — | Does not exist — quality is set globally, per effect, not per shader |
| Temat | Przenosi się 1:1 | Podstawione w realtime |
|---|---|---|
| Liniowe światło (R.3) | Tak — silniki też cieniują liniowo | — |
| Kolor kontra dane (R.11) | Tak — ta sama decyzja sRGB / raw | — |
| Metal/rough, Fresnel (R.13–14) | Tak — ta sama parametryzacja | Zespolony IOR to zawsze przybliżenie Schlick + edge tint, nigdy prawdziwe n + ik |
| Zachowanie energii (R.15) | Rozumowanie tak | Kompensacja multiscatter GGX to zwykle dopasowana krzywa, nie całkowanie |
| Oświetlenie globalne (R.21) | — | Przestrzeń ekranu albo ray tracing z limitem odbić; światło spoza ekranu pochodzi z grubszego cache'u |
| Subsurface (R.16–17) | Intencja looku tak | Ekranowy profil dyfuzji, nie transport random-walk — cienka geometria traci transmisję |
| Displacement (R.20) | Dane wysokości tak | Głównie parallax i detal normalnych; prawdziwa teselacja to budżetowana geometria, nie darmowy mikrodetal |
| Włosy i tkaniny (R.19) | Model cieniowania tak | Karty i LOD-y pasm zamiast pełnych krzywych |
| AOV i debugowanie (R.23) | Koncept tak | Tryby podglądu buforów, nie dowolne LPE |
| Sampling per materiał | — | Nie istnieje — jakość ustawia się globalnie, per efekt, nie per shader |
Level of detail (LOD). The same asset exists in several geometric and material versions, swapped by distance. A look approved on LOD0 in a close-up says nothing about the silhouette two LODs down, where the normal map may already be baked flat and the clear coat switched off entirely. Poziom szczegółowości (LOD). Ten sam asset istnieje w kilku wersjach geometrycznych i materiałowych, przełączanych odległością. Look zatwierdzony na LOD0 w zbliżeniu nie mówi nic o sylwetce dwa LOD-y niżej, gdzie normalna może być już wypalona na płasko, a coat wyłączony całkowicie.
Shader permutations. A material with switchable features doesn't compile once — it compiles once per combination of switches, per platform. This is why engines distinguish a static switch (compiles a variant, costs build time) from a dynamic parameter (costs frame time), a distinction with no counterpart in an offline shader. Permutacje shaderów. Materiał z przełączanymi funkcjami nie kompiluje się raz — kompiluje się raz na każdą kombinację przełączników, na każdą platformę. Dlatego silniki rozróżniają przełącznik statyczny (kompiluje wariant, kosztuje czas builda) od parametru dynamicznego (kosztuje czas klatki) — rozróżnienie bez odpowiednika w shaderze offline.
Temporal accumulation. TAA and upscalers reuse the previous frames' pixels to pay for the samples the current frame couldn't afford. That is a genuine lookdev concern, not a graphics-programmer detail: fine, high-frequency roughness detail that reads beautifully in a still can shimmer, smear or ghost in motion, and you will only ever see it by moving the camera. Akumulacja czasowa. TAA i upscalery używają pikseli z poprzednich klatek, żeby zapłacić za próbki, na które bieżąca klatka nie mogła sobie pozwolić. To jest realny problem lookdevu, nie szczegół dla programisty grafiki: drobny, wysokoczęstotliwościowy detal roughness, który świetnie czyta się na stopklatce, potrafi migotać, rozmazywać się albo zostawiać smugi w ruchu — i zobaczysz to wyłącznie ruszając kamerą.
Auto-exposure. Games adapt exposure to what the player is looking at. Judging a material while the exposure moves under it is like grading through a viewer with an unpredictable transform (Chapter 6) — the first thing to do in any realtime lookdev scene is to pin exposure to a fixed value, which Chapter 26 comes back to in detail. Auto-ekspozycja. Gry dopasowują ekspozycję do tego, na co patrzy gracz. Ocenianie materiału, gdy ekspozycja pod nim pływa, to jak grading przez viewer z nieprzewidywalną transformacją (Rozdział 6) — pierwszą rzeczą do zrobienia w każdej scenie lookdevowej realtime jest przybicie ekspozycji do stałej wartości, do czego szczegółowo wraca Rozdział 26.
Chapter 22 built the turntable as the test that catches a material which only works from one angle. In realtime that test grows a second axis. The player walks around the asset, so every angle happens; the game has a day cycle, so every light direction and colour temperature happens; the game ships on several hardware tiers, so several quality settings happen. Approving a look means approving the worst plausible combination of those, not the best one. Rozdział 22 zbudował turntable jako test wyłapujący materiał, który działa tylko z jednego kąta. W realtime ten test dostaje drugą oś. Gracz obchodzi asset dookoła, więc zdarzy się każdy kąt; gra ma cykl dobowy, więc zdarzy się każdy kierunek i każda temperatura barwowa światła; gra wychodzi na kilku poziomach sprzętu, więc zdarzy się kilka ustawień jakości. Zatwierdzenie looku oznacza zatwierdzenie najgorszej prawdopodobnej kombinacji z nich, nie najlepszej.
The practical form this takes is a lookdev level — a scene inside the game itself holding the calibration spheres, the grey/chrome balls, a macbeth chart and the assets under review, lit by a small set of saved lighting presets (noon, overcast, dusk, interior practical) that can be cycled instantly. It is the same instrument as the HDRI rig from Chapter 21, rebuilt inside the shipping renderer, and it is the single most useful thing to set up before authoring any material in an engine. Praktycznie przybiera to formę poziomu lookdevowego — sceny wewnątrz samej gry, w której stoją kule kalibracyjne, szara i chromowana kula, tablica Macbetha i oceniane assety, oświetlone małym zestawem zapisanych presetów świetlnych (południe, zachmurzenie, zmierzch, wnętrze z lampą), przełączanych natychmiast. To dokładnie ten sam przyrząd co rig HDRI z Rozdziału 21, odbudowany wewnątrz docelowego renderera, i to najbardziej użyteczna rzecz do postawienia, zanim zaczniesz autorować jakikolwiek materiał w silniku.
↓ raytracing-book, Appendix AH — what render-time displacement and subdivision actually cost, offline↓ raytracing-book, Dodatek AH — ile naprawdę kosztuje displacement i subdivision w czasie renderu, offlineThe most common failure when a VFX-trained artist moves to an engine isn't a wrong parameter — it's judging a material in a still, at a fixed exposure, on the highest quality preset, from a camera distance no player will ever hold. The material is then genuinely correct and still looks wrong in the game. Move the camera, cycle the lighting presets, and drop the quality setting one tier before calling anything final. Najczęstsza porażka artysty przychodzącego z VFX do silnika to nie zły parametr — to ocenianie materiału na stopklatce, przy stałej ekspozycji, na najwyższym presecie jakości, z odległości kamery, której żaden gracz nigdy nie utrzyma. Materiał jest wtedy naprawdę poprawny i mimo to wygląda źle w grze. Rusz kamerą, przełącz presety świetlne i zejdź o jeden poziom jakości, zanim uznasz cokolwiek za skończone.
This chapter set the constraints that every engine works under. Chapter 25 takes the most widely used of them — Unreal Engine 5 — and maps its material system onto the vocabulary of Chapters 13–15: what a master material is, why instances matter more here than anywhere in VFX, and what Substrate changes about the fixed shading-model list above. Ten rozdział ustawił ograniczenia, w których pracuje każdy silnik. Rozdział 25 bierze najpowszechniejszy z nich — Unreal Engine 5 — i mapuje jego system materiałów na słownictwo Rozdziałów 13–15: czym jest master material, dlaczego instancje znaczą tu więcej niż gdziekolwiek w VFX i co Substrate zmienia w opisanej wyżej zamkniętej liście modeli cieniowania.