Kompilacja mapy to zamiana tekstowego pliku *.map na jego binarny odpowiednik *.bsp przez 4 programy: CSG, BSP, VIS, RAD.
Ważna jest kolejność w jakiej uruchamiane są poszczególne programy i jeśli wystąpi błąd w którymkolwiek z nich to następny może nie działać poprawnie, przez co mapa będzie zawierać błędy.
- Kompilator: CSG
Pierwszy z 4 kompilatorów, który pobiera informacje z pliku *.map i na ich podstawie tworzy serię plików *.pt# dla BSP.
Sprawdza pliki tekstur *.wad i includuje je w razie potrzeby. Dokonuje podstawowego sprawdzenia mapy pod względem niepoprawnych solidów oraz ich powierzchni/boków a także wyszukuje źle ułożone/zeskalowane tekstury.
- Kompilator: BSP
Drugi z czterech kompilatorów. Odczytuje pliki *.pt# utworzone przez CSG i na ich podstawie tworzy plik *.ptr dla VIS'a umieszczając w nim informacje: o powierzchniach blokujących ruchy gracza (Clip Planes), tnie mapę (standardowo co 240 jednostek) tworząc w ten sposób mniejsze obszary (Leafs), oraz wyszukuje "przejścia" miedzy nimi (Portals). Na koniec przeszukuje mapę pod względem "przecieków" (LEAK's).
- Kompilator: VIS
Trzeci z czterech kompilatorów. Pobiera on informacje utworzone przez BSP z pliku *.ptr o obszarach na które została podzielona mapa i próbuje określić line-of-sight, czyli linie przez które poszczególne obszary "widzą się" nawzajem.
- Kompilator: RAD
Ostatni z czterech kompilatorów. Pobiera informacje z VIS'a i na ich podstawie określa drogę promieni światła od ich żródła do docelowej tekstury, na której zapisuje informacje o jego natężeniu i kolorze, dzięki czemu silnik graficzny jest zwolniony z tych przeliczeń w czasie gry. RAD potrzebuje dużo RAMu (>128MB), dobrego procesora, jak również zabiera najwięcej czasu podczas całej kompilacji. Duże mapy jak również różne typy świateł padających na teksturę potęgują czas jego pracy.
Zmodyfikowana wersja kompilatora RAD z pakietu Zoner's jest nieporównywalnie szybsza od swojego poprzednika (QRAD). Najwięcej czasu poświęca na zbieranie olbrzymiej ilości tymczasowych informacji (precache data), ale dzięki temu ostatni krok jest bardzo szybki. Wygładzanie cieni zabiera mu nieporównywalnie mniej czasu w porównaniu z przeliczaniem dużej ilości łat oraz oświtleniem większych obszarów na mapie które "widzą się" nawzajem.
Pracę RAD'a można podzielić na nastepujące kroki:
- BuildFaceLights:
- RAD czyta mapę, zbiera informacje o wszystkich widocznych powierzchniach króre dzieli na mniejsze kawałki (chop) i tworzy dla nich dodatkowe tekstury (lightmapy, inaczej łaty) zawierające (narazie wyzerowane) wartości padającego na nie światła.
- Sumuje wartości wszystkich źródłeł swiatła i dodaje je do wartości głównego oświetlenia. To jest jedyny moment, kiedy przerabiane są parametry zaciemniania _falloff/_fade przekazane w parametrach ZHLT lub jako argument w linii poleceń.
- Wyszukuje tekstury zawarte w pliku lights.rad i dodaje podane tam wartości oświetlenia do wszystkich odpowiadających im łat.
- BuildVisLeafs:
- Używając informacji z VIS'a, tworzy strukturę VisMatrix, zawierającą informacje, które łaty "widzą się" nawzajem. Ta struktura potrafi się mocno rozrosnąć i w najgorszym wypadku, dla 65535 łat zapotrzebowanie na pamięć RAM może wynieść:
(65535 * 65535 / 16) ~= 256MB!
- MakeScales:
- Korzystając z dopiero co obliczonego VisMatrix, RAD na tym etapie wylicza skale transferów światła pomiędzy łatami (tzn. ile światła odbija się od jednej łaty i trafia do drugiej). Rozmiar tych danych zależy od wielkości mapy i standardowo zajmuje 1/2 wielkości jaką zajmuje VisMatrix, czyli w najgorszym wypadku zapotrzebowanie na RAM wyniesie:
256MB (VisMatrix) + 128MB (Scales) = 384MB RAM!
Jeżeli zabraknie nam RAMu, system korzysta z pliku wymiany na dysku twardym. Jeżeli tak się zdarzy, to zauważono, że gdy pierwsze 90% tego procesu zajmuje ok. 20 min, to ostatnie 10% może zająć godziny!!! W takim wypadku są dwa rozwiązania, albo zmniejszyć architekturę mapy, albo dokupić więcej RAMu. - Po tym etapie usuwane są informacje VisMatrix
- SwapTransfers:
- Skale transferów są odwracane i odbicia światła są przeliczane w odwrotnym kierunku.
- Każda lightmapa posiada teraz listę wszystkich pozostałych lightmap z którymi "widzi się" nawzajem.
- Bounce x:
- Poziom odbitego światła każdej lightmapy jest dodawany do innych lightmap które "widzą się" nawzajem zgodnie z obliczeniami z MakeScales.
- Cały proces powtarzany jest tyle razy ile podano w parametrze X
- FinalLightFace:
- Zakumulowany poziom światła jest sumowany ze światłem ogólnym a następnie ta wartość zostaje dodana do lightmapy każdej powierzchni na mapie.
- W końcu następuje zapis całej informacji o oświetleniu mapy do pliku *.bsp
|
