CELL CITY

Geometria ma początek w rzeczywistym układzie miasta. Dostarczone przetworzone dane zawierają 7 770 rekordów budynków podzielonych na 233 fragmenty przestrzenne; liczby te uzgodniono z plikiem binarnym i metadanymi. Obecność osób za oknami jest wyobrażona. Oświetlona kondygnacja to wartość wygenerowana proceduralnie, a nie obserwacja człowieka czy zajętego pomieszczenia.

Przydział jest celowo prosty: identyfikator fragmentu dzielimy przez sześć, a reszta jest identyfikatorem jego workera. Przydział nie zmienia się wraz z ruchem kamery. Pięć workerów odpowiada za 39 fragmentów każdy, a ostatni za 38. Za tą pozorną równowagą kryje się istotna różnica: fragmenty zawierają różną liczbę budynków o różnych rozmiarach, więc taka sama liczba fragmentów nie oznacza takiej samej ilości danych.

Wybierz workera na diagramie, a następnie sprawdź jeden z przypisanych mu fragmentów. Siatka pokazuje środki fragmentów, a nie obrysy poszczególnych budynków. Eksperyment workera ustala widoczność na podstawie brył ograniczających wyznaczonych z rzeczywistych wierzchołków. Tabela położeń i wymiarów budynków wystarcza do badania przydziału oraz obciążenia związanego z oknami; te narzędzia nie wymagają wczytywania pełnej geometrii do renderowania.

Tabela budynków zajmuje 20 bajtów danych na budynek: cztery wartości Float32 opisujące położenie i wymiary oraz cztery bajty typu użytkowania i ziarna losowego. Szczegółowy stan okien dodaje jeden bajt na każde modelowane okno, a na każdy budynek — osiem bajtów wymiarów okien i cztery bajty buforowanych pionowych pasm oświetlenia. Zestawienie obejmuje tablice, które pozostają w workerze po obsłużeniu komunikatu.

Worker przechowuje również metadane. Środki fragmentów, ich dokładne granice, identyfikatory i flagi odrzucenia zajmują w obecnej implementacji łącznie 45 bajtów na przypisany fragment. Ten koszt istnieje jeszcze przed przyjęciem pierwszego szczegółowego stanu okien. Na diagramie metadane dotyczą całego wybranego workera, a pozostałe wiersze opisują wybrany fragment. Inne buforowane fragmenty dodawałyby własne tablice.

Rozwinięcie wszystkich przypisanych fragmentów daje dla workera 4 obliczoną górną granicę 250 060 bajtów, łącznie z metadanymi. Wartość tę przeliczono na podstawie dostarczonych tabel. Nie oznacza to, że przelot kamery osiąga taki poziom. W tym modelu dane mieszczą się w 256 KiB, natomiast faktycznie przechowywany zestaw zależy od historii obserwacji i wybranego budżetu.

To model przechowywanych tablic typowanych, a nie pomiar całkowitej pamięci przeglądarki. Nie obejmuje obiektów JavaScript, środowiska wykonawczego i kodu, zasobów GPU ani komunikatów w trakcie przesyłania. Jasno określony zakres pozwala sprawdzić limit i zapobiega pomyleniu małej wartości na wskaźniku z kosztem całego miasta.

Gdy pobliski fragment potrzebuje szczegółowych okien, jego tabela budynków jest już używana. Worker najpierw sprawdza, czy cały nowy zestaw danych zmieści się przy zachowaniu tego aktywnego wpisu. Następnie usuwa starsze, nieprzypięte wpisy, aż zwolni wystarczająco dużo miejsca. Jeśli aktywna tabela, metadane i żądane szczegóły nie mieszczą się razem, rezygnuje ze szczegółów i wylicza oświetlenie przybliżone.

Stan okien, ich wymiary i bufor pasm są przedmiotem jednej decyzji o przyjęciu do pamięci. Rachunek nie dopuszcza najpierw dużej tablicy, by dopiero później dodać mniejsze tablice towarzyszące. Przy twardym limicie ma to znaczenie: każdy przechowywany bajt musi wejść do tej samej decyzji, nawet jeśli jedna tablica wygląda niepozornie na tle pozostałych.

Poniższa sekwencja jest przygotowanym scenariuszem testowym, a nie próbką obciążenia miasta: dwa fragmenty zawierają po sześć wysokich budynków i współdzielą workera z limitem 64 KiB. Najpierw docierają obie tabele, potem A otrzymuje szczegółowe okna, a następnie prosi o nie B. Wynik pokazuje rzeczywiste wpisy w pamięci podręcznej i liczbę usunięć zwróconą przez workera. Inspekcja tylko do odczytu niezależnie sumuje również rozmiary zachowanych wpisów i sprawdza, czy ta suma wraz z metadanymi odpowiada zgłoszonej wartości całkowitej.

Obecny worker żąda szczegółowych okien, gdy fragment jest widoczny, a jego środek znajduje się w odległości mniejszej niż 560 metrów. Zwalnia te dane okien, gdy kamera oddali się na ponad 1 150 metrów. Pomiędzy tymi progami wcześniej przydzielona tablica okien może pozostać w pamięci, choć bieżący wynik korzysta z tańszego pasma przybliżonego lub nie zwraca żadnej aktualizacji oświetlenia.

Sama chwilowa odległość nie wyjaśnia więc, co pozostaje w pamięci. Dotarcie na odległość 600 metrów z pustą pamięcią podręczną różni się od powrotu w to samo miejsce po wcześniejszym zbliżeniu. Tabele budynków mają inny czas życia: usuwa je z pamięci podręcznej brak miejsca, a nie odległość. Zestawienie bajtów i bieżący tryb oświetlenia odpowiadają na różne pytania.

To narzędzie zachowuje dane jednego rzeczywistego fragmentu, ustala stały czas symulacji i podaje testowe płaszczyzny zapewniające pełną widoczność. Następnie wykonuje przygotowaną sekwencję zbliżania i oddalania. To celowe uproszczenie oddziela zasady przyjmowania i zwalniania danych od zmian bryły widzenia kamery; nie odtwarza całego renderowanego przelotu. Porównaj obie wizyty w odległości 600 metrów i zobacz, które tablice pozostają.

Zapisana krzywa korzysta z tego samego rzadko próbkowanego obciążenia przy każdym budżecie: 54 dokładnie określonych ustawień kamery, dwóch partii zadań workera na ustawienie, stałych chwil czasu i granic wyznaczonych z rzeczywistych wierzchołków. Każdy przebieg rozpoczyna się od nowych workerów z docelowym budżetem i od razu przesyła im tabele budynków. Zapis wygenerowano w Node 22.11.0. Jest to odtworzenie działania kodu na jawnej sekwencji wejściowej, a nie ciągły przelot w przeglądarce ani test szybkości renderowania.

Artykuł i pełne demo używają tego samego kodu workera. Artykuł udostępnia dodatkowe ustawienia budżetu. Wybierz jednego workera i sprawdź lokalnie wybrany budżet albo przejdź przez 13 ustawień od 8 do 192 KiB. Opcja 256 KiB jest osobnym punktem odniesienia. Koła pokazują zapisany wynik z Node, a kwadraty — liczniki rzeczywiście zwrócone w tej przeglądarce. Rozbieżne wyniki pozostają widoczne. Czasu obliczeń ani oczekiwania nie zastępuje tu wymyślona liczba klatek na sekundę.

Mniej pamięci nie gwarantuje gładkiej, monotonicznej odpowiedzi. Bardzo mały budżet może odrzucić kosztowny stan okien i użyć pasma przybliżonego. Nieco większy może go przyjąć, a potem usunąć tabele potrzebne w dalszej części sekwencji. Czytaj razem liczniki usunięć, przejść na przybliżenie i aktualizacji oświetlenia. Brak aktualizacji światła nie oznacza braku budynku: w pełnym demie geometria pozostaje w GPU, a na niej może pozostać niezmienione pasmo.

W zapisanej sekwencji przy 128 KiB i większych budżetach nie wystąpiły usunięcia z pamięci podręcznej. Ta obserwacja dotyczy tego obciążenia; zmiana ścieżki, rozgrzewki lub kolejności komunikatów zmienia eksperyment. Opcjonalny dźwięk jest domyślnie wyłączony. Po włączeniu krótki, cichy sygnał syntetyczny może zabrzmieć dopiero wtedy, gdy rzeczywista partia zadań workera zgłosi wzrost licznika usunięć; częstotliwość sygnałów jest ograniczona. To sygnał pomiarowy, nie ścieżka dźwiękowa miasta.

Model okien wyznacza liczbę kondygnacji i kolumn z wymiarów budynku, a następnie ogranicza te wartości. W sprawdzonym kodzie budynek może zażądać najwyżej 80 modelowanych kondygnacji i 72 kolumn. Limity ograniczają nakład obliczeń proceduralnych. Nie zmieniają źródłowej geometrii budynku ani nie potwierdzają, że jego wysokość zmierzono w terenie.

Narzędzie tworzy jawnie syntetyczne żądanie: 46 budynków o wybranej wysokości i promieniu 33 metrów. Wyświetlane zestawienie obejmuje ich tabele, szczegółowe stany, wymiary, bufor pasm i przypisane metadane. Zwiększ wysokość, aby zmienić żądanie, a następnie uruchom workera z budżetem 256 KiB. Dane wejściowe przygotowano do eksperymentu; tych wymiarów nie przypisuje się żadnemu rzeczywistemu budynkowi w Shibuyi.

Istotnym wynikiem jest decyzja o przyjęciu danych. Jeśli wszystkie szczegóły się mieszczą, worker je zachowuje. Jeśli nie, szczegółowe tablice nie są przydzielane, a wynik zawiera oświetlenie przybliżone. Zmierzona liczba przechowywanych bajtów może być znacznie mniejsza od obliczonego żądania, ponieważ odrzucone żądanie nie zajmuje pamięci. Dlatego diagram oddziela ilość żądaną od faktycznie przechowywanej.