Animacja policzona w jednym programie musi trafić bez zmian do drugiego — plik, który zamraża tylko kształt, nie recepturę na jego policzenie.
Rozdział 3 pokazał mapę działów: layout, animacja, fx, lighting, comp — każdy w innym programie DCC. Animator pracuje w Mayi na rigu z kontrolerami. Artysta FX potrzebuje tej samej, gotowej animacji w Houdinim, żeby symulować na niej ubranie i włosy. Problem: Houdini nie rozumie riga Mayi — nie zna jej węzłów, jej historii konstrukcyjnej, jej systemu deformerów. Gdyby jedynym sposobem przekazania animacji było przesłanie całej sceny Mayi, każdy odbiorca musiałby mieć Mayę, ten sam rig i identyczne wersje wszystkich wtyczek. To rozwiązanie kruche i wolne. Alembic istnieje po to, żeby tego uniknąć.
Kluczowe rozróżnienie brzmi: przepis kontra wynik. Rig w Mayi to przepis — zestaw kontrolerów, deformerów i zależności, które obliczają pozycję każdego wierzchołka w danej klatce, ale same w sobie nie są tą pozycją. Alembic zapisuje wynik tego obliczenia: dla każdej klatki, dla każdego wierzchołka, dokładną pozycję w przestrzeni — bez informacji o tym, jak ta pozycja powstała. To proces nazywany bakingiem (zapiekaniem). Odbiorca takiego pliku nie musi rozumieć riga, bo rig już wykonał swoją pracę, zanim plik powstał — zostaje tylko czysta geometria, zmieniająca kształt klatka po klatce.
Plik Alembic (rozszerzenie .abc) przechowuje hierarchię obiektów bardzo podobną do tej, którą widzisz w outlinerze DCC — grupy, siatki (mesh), krzywe, chmury punktów, kamery — gdzie każdy obiekt ma zestaw atrybutów próbkowanych (sampled) w kolejnych klatkach: pozycję, orientację, kształt geometrii. Format jest zoptymalizowany pod szybki, sekwencyjny odczyt — dokładnie to, czego potrzebuje program odtwarzający animację klatka po klatce — kosztem tego, że nie da się go sensownie edytować w miejscu. Chcesz zmienić coś w animacji zapisanej w Alembicu? Wracasz do źródła (riga w Mayi), zmieniasz tam, i zapiekasz nowy plik.
Alembic celowo robi jedną rzecz. Nie niesie informacji o materiałach ani shaderach — surfacing z Rozdziału 3 to osobna warstwa, dołączana już po stronie odbiorcy (Rozdział 11 pokaże, jak USD spina te warstwy w jedną całość). Nie jest też edytowalny w sensowny sposób — traktuj go jako zdjęcie stanu, nie jako plik roboczy. I, tak jak każdy inny wynik pracy w tej książce, cache Alembic jest publikowany dokładnie w mechanizmie z Rozdziału 7: dostaje własny numer wersji, trafia do publish/, i to właśnie ta opublikowana wersja — nie plik z work/ animatora — trafia do FX, lightingu i compu.
Alembic rozwiązuje wymianę samej geometrii. Następny rozdział pokazuje USD — format, który idzie o krok dalej i pozwala złożyć całą scenę, z materiałami i wariantami, z tysięcy osobnych assetów naraz.