Nvidia RTX Mega Geometry 2.0 zastępuje stałą geometrię strumieniowaniem na żądanie

Nvidia udostępniła Nvidia RTX Mega Geometry 2.0, dodając strumieniowanie geometrii na żądanie dla scen z ray tracingiem, które przekraczają dostępną pamięć VRAM karty graficznej. Zamiast wymagać, by każda siatka źródłowa stale pozostawała w pamięci, SDK wybiera klastry ciągłych poziomów szczegółowości w ramach zdefiniowanego budżetu pamięci.

To rozróżnienie odwraca znany kompromis graficzny. Twórcy nie muszą już uznawać, że scena jest po prostu zbyt duża dla ray tracingu. Mogą pozwolić rendererowi ograniczać szczegółowość geometrii tam, gdzie ma ona najmniejsze znaczenie, zachowując wyższy poziom detali w pobliżu kamery.

Aktualizacja pojawia się dwa tygodnie przed premierą Gears of War: E-Day, zaplanowaną na 6 października, w którym — według Nvidia — wykorzystywana jest technologia RTX Mega Geometry. Ani Nvidia, ani studio The Coalition nie potwierdziły jednak publicznie, że gra korzysta z wersji 2.0 lub jej nowej ścieżki strumieniowania.

Nvidia RTX Mega Geometry 2.0 zmienia to, co musi zmieścić się w VRAM

Najważniejszą zmianą nie jest kolejny wzrost pojemności obsługiwanej liczby trójkątów. To nowy sposób decydowania, które trójkąty zasługują na miejsce w pamięci w każdej klatce.

Nvidia wprowadziła RTX Mega Geometry, aby ograniczyć koszt budowania struktur akceleracyjnych ray tracingu dla bardzo szczegółowych, klastrowych siatek. Wersja 2.0 rozwija ten projekt o strumieniowanie ciągłych poziomów szczegółowości.

Ciągły poziom szczegółowości, czyli continuous LOD, organizuje siatkę w hierarchię małych klastrów geometrycznych. Renderer może wybierać różne poziomy detali w obrębie jednego obiektu, zamiast przełączać cały obiekt między kilkoma stałymi modelami.

Wybrane klastry są przesyłane do VRAM w miarę potrzeb. Geometria blisko kamery może wykorzystywać gęste klastry, podczas gdy odległe lub częściowo zasłonięte obszary otrzymują mniej detali. Tworzy to zmienny zestaw roboczy zamiast trwałej kopii każdej siatki źródłowej.

Nvidia podsumowuje tę zmianę wyjątkowo bezpośrednio w dzienniku zmian SDK. Geometria źródłowa sceny nie musi już mieścić się w VRAM, a prezentowane detale są ograniczone przydzielonym budżetem pamięci, a nie całkowitą liczbą siatek.

Nie oznacza to, że GPU renderuje nieskończoną geometrię. Oznacza natomiast, że dane źródłowe mogą być większe niż dostępna pamięć graficzna, ponieważ jednocześnie w pamięci musi znajdować się tylko wybrana część.

Gdy zapotrzebowanie przekracza skonfigurowany budżet, system wybiera klastry o niższej szczegółowości. Nie polega na wielokrotnym usuwaniu i ponownym ładowaniu pełnych siatek — wzorcu, który może powodować przestoje, niestabilne czasy klatek lub brakującą geometrię.

Domyślna konfiguracja przykładowa przydziela 2 GB VRAM na dane strumieniowanych siatek. Rezerwuje kolejne 2 GB na struktury akceleracyjne ray tracingu i 4 GB na tekstury materiałów. Twórcy mogą zmienić te przydziały odpowiednio do własnej zawartości i docelowego sprzętu.

Wartości te są ustawieniami przykładowymi, a nie uniwersalnymi wymaganiami. Gotowa gra musi równoważyć geometrię z teksturami, danymi oświetlenia, celami renderowania, zasobami generowania klatek oraz wszystkim innym współdzielącym tę samą pulę pamięci.

Nvidia wydała wersję 2.0 wraz z RTX Kit 2026.3, choć RTX Mega Geometry pozostaje odrębnym SDK w ramach tego zestawu. Towarzyszące wydanie RTX Kit aktualizuje również tekstury neuronowe, renderowanie postaci, dynamiczne oświetlenie, neuronowe cieniowanie i filtrowanie tekstur.

Nowe repozytorium SDK zawiera referencyjny path tracer oraz implementacje dla Direct3D 12 i Vulkan. Obecnie obsługuje kompilacje dla Windows i jest przeznaczone jako materiał do nauki oraz integracji dla twórców silników.

Repozytorium udostępnia dwie ścieżki geometrii. Cluster LOD obsługuje wstępnie przygotowane klastry trójkątów wybierane za pośrednictwem ciągłej hierarchii, natomiast cluster tessellation dynamicznie dzieli i przemieszcza powierzchnie podczas renderowania.

Obie ścieżki mogą działać w jednej scenie. Ta elastyczność ma znaczenie, ponieważ sztywna siatka architektoniczna, odkształcająca się powierzchnia i gęsty zasób postaci niekoniecznie korzystają na tej samej reprezentacji.

Wersja 2.0 zmienia zatem praktyczne pytanie stojące przed twórcami. Wcześniej chodziło o to, czy kompletna reprezentacja ray tracingu zmieści się w pamięci. Teraz pytanie brzmi, ile widocznych detali geometrycznych można utrzymać w ramach kontrolowanego zestawu roboczego.

Próbka Zorah pokazuje skalę i kompromis

Demonstracja Nvidia robi wrażenie, ponieważ jej scena źródłowa jest znacznie większa niż przydział pamięci na rezydentne siatki, lecz pozostaje kontrolowaną przez dostawcę próbką, a nie niezależnym benchmarkiem.

Główna demonstracja wykorzystuje teksturowany eksport glTF sceny Zorah, ozdobnej sceny Nvidia renderowanej metodą path tracingu. Zasób dostępny do pobrania zawiera 1,6 miliarda unikalnych trójkątów i 18,9 miliarda trójkątów po instancjonowaniu.

Zawiera także 2034 siatki i 4357 tekstur. Pobierany pakiet ma około 70 GB, a po rozpakowaniu zajmuje mniej więcej 31 GB danych siatek i 48 GB tekstur.

Liczby te dobrze ilustrują problem pamięci. Żadna typowa konsumencka karta graficzna nie jest w stanie jednocześnie utrzymać w pamięci całego tego pakietu zasobów, jego struktur renderowania oraz pozostałych elementów nowoczesnego silnika.

Opublikowany przez Nvidia zrzut ekranu wskazuje czas klatki 15,5 milisekundy na GeForce RTX 5090 w 4K z DLSS Quality. Wyświetlana klatka obejmuje 56 milionów unikalnych trójkątów i 778 milionów trójkątów instancjonowanych.

Dla tej klatki próbka raportuje około 1,5 GB rezydentnych danych siatek i 2,3 GB klastrowych struktur akceleracyjnych. To znacząca redukcja względem całkowitego geometrycznego rozmiaru sceny źródłowej.

Porównanie wymaga jednak ostrożności. Zasoby źródłowe, geometria rezydentna, liczba trójkątów instancjonowanych i struktury akceleracyjne opisują różne rzeczy. Nie należy traktować ich jako wymiennych miar efektywności pamięciowej.

Instancjonowanie ponownie wykorzystuje dane geometryczne dla powtarzających się obiektów. Scena może zatem raportować bardzo wysoką liczbę trójkątów instancjonowanych bez przechowywania osobnej kopii każdego trójkąta.

Podobnie wartość 1,5 GB rezydentnych siatek nie obejmuje wszystkich zasobów potrzebnych do wygenerowania klatki. Materiały, tekstury, stan oświetlenia, cele renderowania, bufory odszumiania i systemy silnika zużywają dodatkową pamięć VRAM.

Wynik 15,5 milisekundy dla próbki pochodzi również z RTX 5090 działającego w referencyjnej aplikacji Nvidia. Nie przesądza o tym, jak wersja 2.0 działa na starszych GPU, sprzęcie klasy konsolowej ani w kompletnej grze z symulacją i efektami.

Demonstracja potwierdza natomiast mechanizm. Pakiet siatek źródłowych o rozmiarze 31 GB może zasilać znacznie mniejszy zestaw geometrii rezydentnej, ponieważ renderer wybiera odpowiednią hierarchię klastrów dla bieżącego widoku.

Kompromis wizualny pojawia się tam, gdzie przydzielony budżet nie pozwala zachować maksymalnej szczegółowości wszędzie. Odległe, zasłonięte lub mniej istotne powierzchnie otrzymują bardziej uproszczone klastry przed geometrią pierwszoplanową w pobliżu kamery.

Zwykle jest to lepsze rozwiązanie niż usunięcie całego obiektu lub zatrzymanie renderowania, gdy duża siatka trafia do pamięci. Nadal stanowi jednak kompromis jakościowy, dlatego jakość algorytmu selekcji staje się kluczowa.

Słaba polityka wyboru mogłaby powodować widoczne przejścia, niestabilne sylwetki lub zmiany detali podczas ruchu kamery. Dobra polityka powinna umieszczać utratę jakości tam, gdzie gracze mają najmniejszą szansę ją zauważyć.

W wyborze tym pomaga wykorzystywany przez Nvidia hierarchiczny bufor Z. Hierarchiczny bufor Z podsumowuje głębię sceny na wielu rozdzielczościach, umożliwiając rendererowi identyfikowanie geometrii ukrytej za bliższymi powierzchniami.

System może następnie zmniejszać szczegółowość zasłoniętych klastrów, zamiast wydawać pamięć na powierzchnie, które wnoszą niewiele lub nic do końcowego obrazu. Takie podejście bezpośrednio łączy jakość geometrii z widocznością.

Trudniejsze przypadki obejmują cienkie sylwetki, powierzchnie odbijające światło, szybko zmieniające się punkty widzenia oraz geometrię widoczną przez kilka odbić promieni. Ray tracing może wchodzić w interakcję z obiektami, które nie są bezpośrednio widoczne dla kamery.

Twórcy muszą więc brać pod uwagę więcej niż podstawowy obraz przy przydzielaniu szczegółowości. Obiekt o niskim poziomie detali może nadal być wyraźnie widoczny w odbiciu, cieniu lub ścieżce oświetlenia pośredniego.

Próbka Zorah sugeruje, że architektura może obsłużyć ekstremalną, kontrolowaną scenę. Dopiero gotowe gry pokażą, czy te same rozwiązania pozostaną stabilne w warunkach animacji, destrukcji, streamingu, walki i nieprzewidywalnego ruchu gracza.

Jak strumieniowanie geometrii Nvidia przebudowuje zestaw roboczy ray tracingu

RTX Mega Geometry 2.0 traktuje geometrię ray tracingu jako zestaw roboczy ograniczony budżetem, a nie stałą kopię zasobów źródłowych gry.

Ray tracing opiera się na strukturach akceleracyjnych, które pomagają GPU znajdować przecięcia bez sprawdzania każdego promienia względem każdego trójkąta. Struktura akceleracyjna najniższego poziomu, czyli BLAS, organizuje geometrię powiązaną z obiektem lub siatką.

Konwencjonalne procesy pracy mogą stawać się kosztowne, gdy scena zawiera wiele gęstych obiektów lub geometrię często się zmieniającą. Przebudowa dużych struktur pochłania czas obliczeniowy, a utrzymywanie ich w pamięci — pamięć.

RTX Mega Geometry dzieli gęste siatki na mniejsze klastry. Może budować klastrowe struktury akceleracyjne, nazywane CLAS, oraz łączyć je lub ponownie wykorzystywać w większej hierarchii ray tracingu.

Ścieżka cluster LOD w wersji 2.0 rozpoczyna się przed uruchomieniem gry. Twórcy przygotowują siatki źródłowe w ciągłą hierarchię zawierającą klastry geometryczne o różnych poziomach szczegółowości.

Podczas każdej klatki kod przechodzenia przez hierarchię ocenia ją na podstawie czynników takich jak rozmiar projekcji, odległość, widoczność i skonfigurowany budżet pamięci. Następnie wybiera klastry odpowiednie dla bieżącego widoku.

Wymagane klastry trafiają do rezydentnej pamięci podręcznej siatek. Klastry, które przestają być wartościowe, mogą ją opuszczać, dzięki czemu zestaw roboczy zmienia się wraz z kamerą i sceną.

Nvidia wykorzystuje również współdzielenie, buforowanie i scalanie BLAS. Techniki te mają ograniczyć koszt tworzenia większej hierarchii akceleracyjnej w miarę zmiany wybranych klastrów.

Powstały potok przypomina systemy zwirtualizowanej geometrii stosowane w rasteryzacji, zwłaszcza Nanite z Unreal Engine 5. Oba podejścia dzielą złożone siatki na klastry i dobierają poziom detali zgodnie z potrzebami przestrzeni ekranowej.

Nvidia wyraźnie przedstawiła oryginalną technologię jako sposób na przyspieszenie budowy struktur akceleracyjnych dla systemów klastrowych, takich jak Nanite. Jej pierwszy przegląd RTX opisywał kompresję i buforowanie między klatkami jako kluczowe elementy projektu.

Podobieństwo ma swoje granice. Głównym zadaniem Nanite jest rasteryzacja zwirtualizowanej geometrii, podczas gdy RTX Mega Geometry koncentruje się na strukturach akceleracyjnych potrzebnych do śledzenia promieni względem gęstej geometrii.

Gra korzystająca z obu rozwiązań nadal musi koordynować dwie reprezentacje lub integrować je za pośrednictwem silnika. Widoczna powierzchnia rasteryzowana i geometria dostępna dla promieni wtórnych muszą pozostawać wystarczająco zbliżone, aby uniknąć rozbieżności w oświetleniu lub odbiciach.

Ta koordynacja jest jednym z powodów, dla których technologia ma znaczenie wykraczające poza nagłówkowe liczby trójkątów. Gęsta geometria stała się już praktyczna w scenach rasteryzowanych, ale śledzenie promieni dla równie szczegółowej geometrii generuje dodatkowe koszty pamięci i aktualizacji.

Siatki zastępcze często wypełniały tę lukę. Gra może rasteryzować gęsty model, jednocześnie śledząc promienie względem uproszczonej reprezentacji, zmniejszając obciążenie kosztem dokładności geometrycznej.

Różnica ta może być widoczna w odbiciach, cieniach, okluzji otoczenia i oświetleniu pośrednim. Drobne cechy powierzchni widoczne w głównym obrazie mogą nie występować w strukturze ray tracingu.

RTX Mega Geometry stara się zachować bliższy związek między widoczną a śledzoną geometrią. Robi to bez wymogu, by reprezentacja o najwyższym poziomie szczegółowości pozostawała stale rezydentna wszędzie.

Pierwotna wersja obsługiwała już oparte na klastrach struktury przyspieszające, dynamiczną teselację i powierzchnie z mapowaniem przemieszczeń. Przykłady Vulkan od Nvidia prezentowały także koncepcje ciągłego LOD, zanim wersja 2.0 skonsolidowała je w głównym SDK.

Wersja 2.0 czyni ścieżkę streamingu centralną, użyteczną częścią implementacji referencyjnej. Obejmuje ona przygotowywanie zasobów, przechodzenie po hierarchii, buforowanie i budżetowanie na poziomie sceny, zamiast pozostawiać deweloperów z odizolowanymi próbkami technicznymi.

To jest rzeczywisty postęp. Funkcja sprzętowa lub rozszerzenie API mają ograniczoną wartość, jeśli każde studio musi samodzielnie tworzyć otaczający je pipeline treści i menedżer pamięci.

SDK daje zespołom silnikowym konkretną architekturę do przeanalizowania. Mogą ją wdrożyć, zmodyfikować poszczególne elementy albo wykorzystać jako punkt odniesienia wydajności dla własnego systemu.

Integracja nadal będzie wymagać znacznej pracy. Studia muszą przetwarzać zasoby, zarządzać przepustowością nośników danych, koordynować streaming materiałów, dostrajać progi jakości i testować przejścia na obsługiwanych GPU.

Muszą także zdecydować, jak płynnie system ma się skalować. Konfiguracja, która wygląda stabilnie na wysokiej klasy GPU Blackwell, może wymagać innych budżetów klastrów lub celów jakości na starszej karcie RTX.

Nvidia podaje, że SDK obsługuje Direct3D 12 i Vulkan w systemie Windows. Technologia bazowa działa na GPU RTX począwszy od serii RTX 20, natomiast Blackwell oferuje konkretne optymalizacje sprzętowe i RT Core dla Mega Geometry.

Ta szeroka kompatybilność sprzyja eksperymentom, ale kompatybilność nie oznacza jednakowej wydajności. Praktyczna wartość na każdej generacji będzie zależeć od przepustowości budowania, przepustowości pamięci, zachowania cache oraz złożoności sceny.

Prawdziwym przeciwnikiem jest stała rezydencja, nie inny producent GPU

Główna rywalizacja toczy się między geometrią ray tracingu stale rezydentną w pamięci a streamowaną, ograniczoną budżetem reprezentacją, która dopuszcza zmienny poziom szczegółowości.

Kuszące byłoby przedstawienie Nvidia RTX Mega Geometry 2.0 jako kolejnej rundy Nvidia kontra AMD. Takie porównanie jest przedwczesne, ponieważ ogłoszenie nie zapewnia równoważnych testów między producentami ani wspólnego obciążenia.

Bardziej użyteczne porównanie dotyczy architektury renderowania. Tradycyjne pipeline’y ray tracingu zakładają, że wymagana reprezentacja geometryczna i jej struktury przyspieszające zmieszczą się w dostępnym budżecie pamięci.

Deweloperzy mogą upraszczać zasoby, ograniczać obiekty śledzone promieniami, stosować siatki zastępcze lub redukować gęstość sceny, aby spełnić to założenie. Każdy wybór nakłada stały limit na pewnym etapie pipeline’u treści.

Streaming przesuwa ten limit. Sceny źródłowe mogą stać się większe, ponieważ renderer utrzymuje jedynie wybrany roboczy zestaw geometrii.

Ceną jest warunkowość szczegółowości. Zależy ona od bieżącego widoku, dostępnego budżetu, jakości hierarchii i szybkości, z jaką mogą nadejść nowe klastry.

Odzwierciedla to szerszą zmianę w grafice. Nowoczesne silniki coraz częściej wirtualizują zasoby, zamiast traktować tekstury i geometrię jako monolityczne zasoby, które muszą pozostać w całości rezydentne.

Wirtualne teksturowanie dzieli duże tekstury na strony i ładuje tylko potrzebne obszary. Streaming siatek i Nanite stosują podobne podejście do widocznej geometrii.

RTX Mega Geometry 2.0 rozszerza tę logikę na struktury używane w ray tracingu. Daje deweloperom kolejny sposób na wymianę pracy związanej z pamięcią masową i streamingiem na ograniczoną lokalną pamięć graficzną.

To podejście jest szczególnie istotne, ponieważ ray tracing konkuruje z innymi, coraz bardziej kosztownymi obciążeniami GPU. Tekstury o wysokiej rozdzielczości, bufory path tracingu, modele renderowania neuronowego, generowanie klatek i odszumiacze wszystkie potrzebują pamięci.

Dodanie większej ilości VRAM rozwiązuje część problemu, ale podnosi koszt karty i nie eliminuje nieefektywnej rezydencji. Większy budżet nadal może zostać przytłoczony przez wystarczająco szczegółowe światy.

Renderer świadomy budżetu oferuje inną odpowiedź. Próbuje sprawić, by jakość wizualna skalowała się wraz z dostępnymi zasobami, zamiast pozwalać, by jedna zbyt duża alokacja wywołała poważne załamanie wydajności.

Wcześniejsze dowody sugerują, że szersze podejście Mega Geometry może zapewniać praktyczne oszczędności. Niezależne testy techniczne Alan Wake 2 wykazały około 1 GB mniejsze użycie VRAM na RTX 4090.

Ten sam test zmierzył 13-procentową poprawę wydajności w natywnym 4K oraz w 4K z DLSS Quality. Porównano wersje gry sprzed i po pierwotnej integracji Mega Geometry, a nie nowy system streamingu z wersji 2.0.

To rozróżnienie ma znaczenie. Wynik potwierdza użyteczność opartych na klastrach struktur ray tracingu, ale nie waliduje wydajności ani jakości obrazu ciągłego streamingu LOD.

Alan Wake 2 ilustruje również dwa różne powody wdrożenia tej technologii. Deweloper może przeznaczyć zaoszczędzoną pamięć i czas przetwarzania na wyższy poziom szczegółowości albo zachować obecną jakość przy jednoczesnej poprawie wydajności.

Druga opcja może być cenniejsza dla wielu wydawanych gier. Gracze często wolą stabilne dostarczanie klatek od wzrostu gęstości geometrii, który trudno zauważyć podczas ruchu.

Dla deweloperów architektura może ograniczyć potrzebę tworzenia osobnych, mocno uproszczonych siatek ray tracingu. Może także umożliwić gęstsze światy bez pozwalania, by struktury przyspieszające zużywały niekontrolowaną część VRAM.

Żadne SDK nie eliminuje jednak potrzeby podejmowania decyzji dotyczących treści. Artyści i zespoły silnikowe nadal potrzebują dobrych siatek źródłowych, znaczących hierarchii klastrów, przewidywalnego zachowania streamingu i progów wizualnych, które sprawdzają się w całej rozgrywce.

Technologia pozostaje także rozwijana pod przewodnictwem Nvidia. Studia wydające gry na konsolach i na komputerach z GPU różnych producentów muszą rozważyć, czy ścieżka specyficzna dla Nvidia zapewnia wystarczające korzyści, by uzasadnić dodatkową integrację i testowanie.

Na wdrożenie wpłyną standardy i porównywalne implementacje różnych producentów. Technika, która naturalnie wpisuje się we wspólne abstrakcje silników, ma większą szansę stać się rutynowa niż taka, która wymaga odizolowanej ścieżki renderowania.

Na razie przewaga Nvidia polega na dostarczaniu działającego kodu, publicznych próbek i sprzętu dostrojonego do odpowiednich operacji klastrowych. Presja konkurencyjna dotyczy najpierw pipeline’ów ze stałą rezydencją, a dopiero później konkurencyjnych implementacji.

Gears of War: E-Day to pierwszy poważny test rzeczywistości

Gears of War: E-Day może przenieść RTX Mega Geometry z technicznego pokazu do testu w wydanej grze, ale Nvidia nie wskazała, której wersji SDK używa gra.

Nvidia twierdzi, że RTX Mega Geometry trafi do Gears of War: E-Day. Opublikowała także rozmowę z The Coalition na temat wykorzystania przez grę technologii Mega Geometry i DLSS.

Moment jest godny uwagi. Nvidia ogłosiła wersję 2.0 22 września, podczas gdy E-Day osiągnęło status gold przed światową premierą 6 października.

Osiągnięcie przez grę statusu gold oznacza, że jej wersja wydawnicza ukończyła ważny etap produkcji. Późne ogłoszenia SDK nie wskazują automatycznie, że nowo opublikowana technologia trafiła do tej wersji.

Wersja 2.0 może formalizować pracę już dostępną dla The Coalition albo gra może korzystać z wcześniejszej implementacji Mega Geometry. Może również używać wybranych komponentów bez wdrażania kompletnej referencyjnej ścieżki streamingu.

Żadne z publicznych ogłoszeń nie rozstrzyga tej kwestii. Sformułowania Nvidia łączą Mega Geometry z grą, ale nie mówią wprost, że E-Day zostanie wydane z wersją 2.0.

Czytelnicy powinni zatem unikać traktowania E-Day jako potwierdzonego dowodu działania nowego systemu ciągłego streamingu LOD. Jest to potwierdzone komercyjne zastosowanie szerszej rodziny RTX Mega Geometry.

Rozróżnienie wpływa na to, co recenzenci mogą testować. Jeśli E-Day korzysta ze ścieżki streamingu, analitycy mogą zbadać skalowanie VRAM, przejścia wizualne, stabilność czasów klatek i wydajność na kilku generacjach RTX.

Jeśli korzysta ze starszej implementacji, gra nadal może demonstrować wartość opartych na klastrach struktur przyspieszających. Po prostu nie może potwierdzić głównej funkcji wersji 2.0.

Październikowa premiera pozostaje ważna, ponieważ środowiska produkcyjne ujawniają problemy, których nie pokażą dema referencyjne. Kompletna gra łączy animację, destrukcję, cząsteczki, streaming, skryptowane wydarzenia, systemy multiplayer i szybki ruch kamery.

Te obciążenia konkurują o czas CPU, przepustowość, dostęp do pamięci masowej i VRAM. System geometrii, który działa dobrze w Zorah, musi zachować to działanie, gdy aktywne jest wszystko inne.

Gra obejmuje także konsole Xbox Series i PC. Specyficzne dla Nvidia funkcje RTX dotyczą wyłącznie odpowiedniego sprzętu PC, podczas gdy The Coalition musi zachować spójne rezultaty artystyczne na każdej obsługiwanej platformie.

Czyni to E-Day użytecznym studium opcjonalnych ścieżek renderowania. Wersja PC może wykorzystywać Mega Geometry do poprawy efektywności ray tracingu bez zmiany podstawowych zasobów ani projektu gry.

Nvidia twierdzi, że integracja zapewnia wyższe liczby klatek, lepszą jakość obrazu i bardziej responsywne sterowanie. Są to twierdzenia firmy, dopóki kontrolowane testy nie oddzielą Mega Geometry od DLSS, generowania klatek, zmian ustawień i różnic sterowników.

Oficjalna premiera 6 października daje recenzentom krótkoterminową okazję do zbadania finalnej wersji. Najbardziej miarodajne testy porównają równoważne ustawienia wizualne ze szczegółowymi pomiarami VRAM i czasów klatek.

Same zrzuty ekranu nie wystarczą. Systemy ciągłego LOD należy oceniać w ruchu, ponieważ przejścia, chybienia cache i presja streamingu ujawniają się, gdy kamera przemieszcza się po scenie.

Testy powinny także obejmować karty z ograniczoną pamięcią. System zaprojektowany tak, by mieścić się w budżecie, ma większą praktyczną wartość, gdy budżet jest napięty.

Karta 8 GB jest szczególnie wymownym celem. Oszczędność lub kontrolowanie kilku gigabajtów ma tam większe znaczenie niż na flagowej karcie z obfitą pamięcią.

Najlepszym wynikiem nie musi być najwyższa średnia liczba klatek. Stabilne czasy klatek, mniej spadków związanych z pamięcią i spójna geometria podczas przemieszczania się lepiej potwierdziłyby główne twierdzenie Nvidia.

Do czasu pojawienia się tych pomiarów E-Day jest obiecującym przypadkiem testowym, a nie werdyktem. Jego status powinien pozostać oddzielony od starannie kontrolowanej demonstracji Zorah.

Na co zwracać uwagę po premierze 2.0

Trzy sygnały pokażą, czy Nvidia RTX Mega Geometry 2.0 stanie się praktyczną warstwą renderowania, czy pozostanie wyspecjalizowaną technologią referencyjną.

Pierwszym sygnałem będzie finalna implementacja Gears of War: E-Day. Nvidia lub The Coalition powinny wyjaśnić, która wersja Mega Geometry zostanie wydana, które tryby z niej korzystają i czy gracze mogą ją bezpośrednio porównać.

Jeśli streaming wersji 2.0 jest aktywny, niezależne pomiary mogą przetestować twierdzenia Nvidia dotyczące budżetu pamięci w warunkach rzeczywistej rozgrywki. Stabilne wyniki na kilku generacjach RTX wzmocniłyby argumenty za wdrożeniem.

Jeśli gra wykorzystuje jedynie wcześniejszą ścieżkę struktur przyspieszających, wersja 2.0 nadal będzie potrzebowała prezentacji produkcyjnej. Nie unieważniłoby to SDK, ale opóźniłoby niezależne dowody dotyczące jego głównej nowej funkcji.

Drugim sygnałem będzie zachowanie obrazu przy rosnącej presji pamięci. Recenzenci powinni badać sylwetki, odbicia, cienie, szybkie obroty, przemieszczanie się i sceny zawierające rozległe zasłonięcia.

Udana implementacja powinna stopniowo obniżać szczegółowość geometrii. Widoczne nagłe pojawianie się detali, opóźnione szczegóły, niezgodności odbić lub nagłe skoki czasów klatek ujawniłyby słabości selekcji albo streamingu.

Testy powinny raportować całkowite użycie VRAM, a nie wyłącznie pamięć rezydentną siatek. Geometria to jedna część klatki, a redukcje w tym obszarze mają znaczenie tylko wtedy, gdy cała alokacja staje się łatwiejsza do opanowania.

Trzecim sygnałem jest wdrażanie tej technologii przez silniki i branżę. Nvidia już oferuje integracje z Unreal Engine oraz publicznie dostępny kod, jednak rutynowe wykorzystanie będzie wymagało narzędzi gotowych do produkcji i strategii międzyplatformowych.

Wsparcie ze strony kolejnych komercyjnych gier pokazałoby, że zespoły mogą integrować tę technologię bez nadmiernych kosztów utrzymania. Szersze wsparcie dla API lub porównywalne implementacje zmniejszyłyby ryzyko uzależnienia się od jednego dostawcy.

Deweloperzy powinni również obserwować publiczne repozytorium. Zmiany dotyczące obsługi platform, narzędzi do debugowania, wypalania zasobów, zarządzania pamięcią podręczną i wskazówek dotyczących wydajności mogą mieć większe znaczenie niż kolejna efektowna scena demonstracyjna.

Nvidia RTX Mega Geometry 2.0 przedstawia jasny argument techniczny: geometria powinna zajmować kontrolowany zestaw roboczy, nawet gdy źródłowy świat jest znacznie większy niż VRAM. To wiarygodny argument, a implementacja referencyjna daje teraz deweloperom coś konkretnego do przetestowania.

Nierozstrzygnięte pozostaje pytanie, czy gracze otrzymają stabilny poziom szczegółowości i wydajność, gdy mechanizm ten trafi do złożonej, wydanej gry. Warto obserwować premierę E-Day, oceniać ruch zamiast nieruchomych obrazów oraz porównywać całkowite zużycie pamięci na kilku GPU. Te wyniki pokażą, czy geometria do ray tracingu ładowana na żądanie jest gotowa stać się standardowym założeniem silników.