Przejdź do treści
Blog

Oversized assets w FiveM: zmniejsz .ytd bez utraty jakości

FiveM pisze, że asset zajmuje 76 MiB pamięci fizycznej? Co znaczy ostrzeżenie o oversized assets, czemu psuje streaming i jak bezpiecznie zmniejszyć .ytd.

Autor: Termi

9 min czytania
  • Streaming
  • Textures
  • Performance
  • Desktop app
Na tej stronie

Odpalasz serwer FiveM, a konsola zapełnia się ostrzeżeniami w rodzaju: „Asset … uses 76.0 MiB of physical memory. Oversized assets can and WILL lead to streaming issues (such as models not loading/rendering).” Większość właścicieli to ignoruje, bo serwer działa. Potem gracze zaczynają zgłaszać drogi zamienione w rozmytą papkę, budynki, które się nie wczytują, i auta jako szare klocki. To właśnie spełnia się to ostrzeżenie. Ten poradnik wyjaśnia, co ono znaczy, ile to za dużo i jak zmniejszyć za duże słowniki tekstur .ytd tak, żeby mapy i auta nie wyglądały gorzej.

W skrócie

Ostrzeżenie znaczy, że jeden streamowany plik potrzebuje więcej pamięci graficznej, niż FiveM chce wczytać naraz, prawie zawsze przez tekstury 4K. Trzymaj każdy .ytd poniżej około 16 MiB pamięci fizycznej. Najszybsza bezpieczna poprawka to odcięcie największych poziomów mip za dużych tekstur. Tak działa Stream Optimizer w FiveDock: jedno kliknięcie i kopia oryginałów.

Co znaczy to ostrzeżenie

Tak wygląda komunikat w konsoli serwera. Twoje nazwy zasobów będą inne:

server console
Asset example_resource/example_props_txd.ytd uses 76.0 MiB of physical memory. Oversized assets can and WILL lead to streaming issues (such as models not loading/rendering).
Asset example_vehicle/example_vehicle+hi.ytd uses 24.0 MiB of physical memory.

Czytaj od lewej:

  • example_resource to zasób, który streamuje plik, czyli folder w katalogu resources.
  • example_props_txd.ytd to sam plik. .ytd to słownik tekstur: paczka obrazków, które gra nakłada na modele. Pliki +hi.ytd trzymają tekstury wysokiej jakości pojazdu.
  • 76.0 MiB of physical memory to ile pamięci graficznej (VRAM) plik zajmuje po wczytaniu. To nie jest rozmiar na dysku i zwykle jest większy.

Serwer wypisuje tę linijkę przy starcie zasobu, więc mówi o problemie, zanim zobaczy go jakikolwiek gracz. Plik i tak jest streamowany. FiveM tylko ostrzega, że każdy gracz, który podjedzie w pobliże, musi teraz wczytać 76 MiB w jednym kawałku.

Czemu za duże assety psują streaming

GTA V wczytuje świat małymi kawałkami, w miarę jak się poruszasz. Trzyma ograniczoną pulę pamięci na to, co jest wokół ciebie, i ciągle coś do niej dokłada i wyrzuca. Jeden słownik tekstur na 76 MiB zabiera sam dużą część tej puli. Gdy kilka takich stoi w jednej części mapy, grze kończy się miejsce i zaczyna wyrzucać rzeczy, których wciąż potrzebuje. Gracze widzą to jako:

  • Utratę tekstur, tzw. city bug: drogi, ściany i ziemia robią się rozmyte i takie zostają.
  • Modele, które się nie wczytują albo nie renderują: budynki, propy czy wnętrza, których nie ma albo które pojawiają się z kilkusekundowym opóźnieniem.
  • Auta bez tekstur albo tylko w modelu niskiej jakości, zwłaszcza w pełnym garażu czy na zlocie.
  • Przycięcia i długie ekrany ładowania, bo duże pliki dłużej się pobierają, czytają i wysyłają do karty graficznej.

Gracze z dużą ilością VRAM zauważają to później niż ci na karcie 4 GB, więc ten sam serwer może wyglądać dobrze dla właściciela i źle dla połowy graczy.

Pamięć fizyczna a wirtualna

Każdy streamowany plik GTA V dzieli się na dwie części. Pamięć wirtualna trzyma strukturę: nazwy, formaty, listę tekstur. Pamięć fizyczna trzyma surowe piksele, które trafiają do karty graficznej. W .ytd prawie cała waga to pamięć fizyczna i właśnie przed nią ostrzega FiveM.

Ile to za dużo?

Zwykły cel, którego trzyma się większość twórców na FiveM, to 16 MiB pamięci fizycznej na asset. Poniżej FiveM milczy. Powyżej dostajesz ostrzeżenie, a im dalej, tym bardziej prawdopodobne są problemy z listy wyżej. 16 MiB to nie twarda granica, ale traktuj to jako budżet na każdy .ytd.

Rozmiar tekstury w pamięci zależy tylko od trzech rzeczy: rozdzielczości, formatu i poziomów mip. Tabela pokazuje jedną teksturę z pełnym łańcuchem mipów:

one texture, with all mip levels
size        DXT1       DXT5       A8R8G8B8 (uncompressed)
4096x4096   10.7 MiB   21.3 MiB   85.3 MiB
2048x2048    2.7 MiB    5.3 MiB   21.3 MiB
1024x1024    0.7 MiB    1.3 MiB    5.3 MiB
 512x512     0.2 MiB    0.3 MiB    1.3 MiB

Jedna tekstura 4096×4096 w DXT5 kosztuje więc 21,3 MiB, więcej niż cały budżet. Paczka mapy z trzema takimi, kilkoma normal mapami i paroma teksturami detali ląduje dokładnie na 76 MiB z przykładu. Nieskompresowana tekstura 4K jest jeszcze gorsza: 85,3 MiB sama. Większość za dużych assetów to po prostu tekstury 4K, których nikt nie potrzebował w 4K.

Znajdź każdy za duży asset na serwerze

Konsola pokazuje ostrzeżenie tylko przy starcie serwera, wymieszane z resztą, i łatwo któreś przeoczyć. Masz dwie lepsze opcje.

  1. Przeszukaj log konsoli pod kątem MiB of physical memory. Każde trafienie podaje zasób i plik. Szukając Oversized assets, pominiesz pliki od 16 do 48 MiB, bo ich linijka kończy się na rozmiarze.
  2. Zostaw to Asset Doctorowi. Czyta każdy zasób na serwerze przez zasób FiveDock i wypisuje każdy słownik tekstur powyżej 16 MiB, z pamięcią graficzną obok rozmiaru na dysku.
Asset Doctor
example_resource  stream/example_props_txd.ytd
  this texture dictionary allocates 76.0 MiB of graphics memory (61.2 MiB on disk),
  more than the 16.0 MiB a pack should stay under

Asset Doctor oznacza też modele, które streamują dwie paczki naraz, i zasoby, które nigdy nie startują, więc jeden skan obejmuje typowe powody, dla których mapa albo auto wygląda źle. Jeśli dwie paczki mają ten sam plik mapy, poradnik o konfliktach map wyjaśnia, co to psuje.

Zmniejsz tekstury .ytd bez utraty jakości

Każda tekstura w .ytd jest zapisana kilka razy: w pełnym rozmiarze, potem w połowie, ćwiartce, jednej ósmej i tak dalej, aż do kilku pikseli. Te kopie to poziomy mip. Gra wybiera poziom, który pasuje do tego, jak duża jest powierzchnia na ekranie. Ściana 20 metrów dalej dostaje mały mip, a pełny rozmiar jest używany dopiero, gdy przyciśniesz do niej twarz.

To daje sposób na zmniejszenie tekstury bez ruszania jej pikseli: odcięcie największych poziomów mip. Tekstura 4096×4096 bez dwóch górnych poziomów staje się teksturą 1024×1024, której piksele są dokładnie tymi, które gra i tak pokazywała z każdej normalnej odległości. Nic nie jest skalowane, kompresowane ani kodowane od nowa, więc nie pojawia się nowe rozmycie ani kwadratowe artefakty. Każdy odcięty poziom zmniejsza pamięć mniej więcej do jednej czwartej.

Pamiętaj, ile masz ekranu. Na monitorze 1920×1080 nawet ściana na cały widok nigdy nie pokaże więcej niż około 2000 pikseli w poprzek, więc tekstura 4K na latarni czy drzwiach auta to pamięć wydana na detal, którego żaden gracz nie zobaczy.

Ręcznie, i gdzie jest haczyk

Bez narzędzia wygląda to tak:

  1. Otwórz .ytd w OpenIV albo CodeWalkerze i wyeksportuj wszystkie tekstury.
  2. Zmniejsz duże w edytorze grafiki.
  3. Zapisz je znowu jako DDS, wybierając właściwy format DXT i generując nowe mip mapy.
  4. Zaimportuj je z powrotem, zapisz .ytd i zrestartuj.

To działa, ale zapis do DXT kompresuje obraz drugi raz, a każde przejście dodaje artefakty, zwłaszcza na normal mapach i napisach. Na serwerze z kilkuset autami i kilkunastoma mapami to też dni pracy.

Zmniejsz je Stream Optimizerem

Stream Optimizer w aplikacji desktopowej FiveDock robi sztuczkę z poziomami mip dla każdego .ytd w folderze naraz. Przycina za duże tekstury do największego poziomu mip, który mieści się w limicie, a resztę pikseli zostawia bajt w bajt taką, jaka była.

  1. Otwórz Optymalizacja streamu w aplikacji desktopowej i wybierz zasób albo cały folder resources.
  2. Wybierz preset (niżej) i folder na oryginały.
  3. Kliknij Skanuj. Zobaczysz każdy plik, który by się zmienił, każdą teksturę z rozmiarem przed i po oraz ile pamięci gry oszczędzasz.
  4. Kliknij Optymalizuj i zrestartuj serwer.

To samo z wiersza poleceń, dla pliku z ostrzeżenia wyżej:

fivedock optimize
> fivedock optimize C:\server\resources\example_resource
1 .ytd file under C:\server\resources\example_resource, textures over 1024px
  stream\example_props_txd.ytd  76.0 MiB -> 12.0 MiB
      example_wall_d  4096x4096 -> 1024x1024  DXT5
      example_wall_n  4096x4096 -> 1024x1024  DXT5
      example_floor_d  4096x4096 -> 1024x1024  DXT1
      example_floor_n  4096x4096 -> 1024x1024  DXT1
      example_trim_d  2048x2048 -> 1024x1024  DXT5
      kept example_sign_emis  2048x2048  emissive
Would free 64.0 MiB of game memory. Nothing was written; add --apply --backup <dir>.

Skan niczego nie zapisuje. Dodaj --apply --backup <dir>, żeby zapisać mniejsze pliki i zachować oryginały w tym folderze. W tym przykładzie plik spada z 76,0 MiB do 12,0 MiB, poniżej budżetu 16 MiB, i przy następnym starcie ostrzeżenia nie ma.

Który preset wybrać

  • Bezpieczny niczego nie zmniejsza. Naprawia tylko skompresowane tekstury script_rt, przed którymi FiveM też ostrzega.
  • Lekki zostawia tekstury do 2048 px. Dobry do assetów, które gracze oglądają z bliska, jak salon samochodowy czy szyld.
  • Zbalansowany zostawia tekstury do 1024 px. Domyślny i właściwy dla większości map, propów i aut.
  • Wydajność zostawia tekstury do 512 px. Do propów w tle i serwerów, których gracze mają starsze karty graficzne.

Zacznij od Zbalansowanego, przejedź obok tego, co się zmieniło, i przejdź na Lekki tylko dla tych kilku assetów, gdzie widzisz różnicę.

Czego nigdy nie rusza

  • Render targety (script_rt_* i scr_*) zachowują rozmiar, bo skrypty rysują po nich w dokładnej rozdzielczości. Skompresowane są zamieniane na nieskompresowane tego samego rozmiaru, tak jak wymaga FiveM.
  • Tekstury emisyjne: nazwy z emis, glow, neon albo kończące się na _em zachowują rozmiar, bo wzory świateł i neony pokazują każdy utracony piksel.
  • Tekstury już poniżej limitu i wszystko w formacie, którego nie zna, zostaje dokładnie takie, jakie było.

Nic nie ginie

Gdy wybierzesz folder na kopie, oryginały trafiają tam, zanim cokolwiek zostanie zapisane. Żeby cofnąć, skopiuj je z powrotem.

Obniż lodDistances w autach addon

W pojazdach tekstury to połowa historii. Każde auto w vehicles.meta ma listę lodDistances: odległości w metrach, przy których przełącza się z modelu wysokiej jakości na prostsze, a ostatnia wartość mówi, z jak daleka jest w ogóle rysowane. Wiele aut addon ma wartości daleko powyżej gry bazowej, więc każde auto na zatłoczonej ulicy jest trzymane w pełnej jakości, razem z +hi.ytd, z odległości setek metrów.

vehicles.meta
<Item>
  <modelName>example_car</modelName>
  <lodDistances content="float_array">
    40.000000
    80.000000
    200.000000
    400.000000
    1000.000000
    1000.000000
  </lodDistances>
</Item>

Zaznacz Optymalizuj odległości LOD w Stream Optimizerze albo dodaj --lod w wierszu poleceń. Każda wartość jest obniżana najwyżej do 15, 30, 70, 140, 250 i 250 metrów, blisko gry bazowej. Wartość, która już jest niższa, nigdy nie jest podnoszona, a w pliku zmieniają się tylko liczby.

fivedock optimize --lod
> fivedock optimize C:\server\resources\example_vehicle --lod --no-textures
1 .meta file with lodDistances
  data\vehicles.meta  example_car  40 / 80 / 200 / 400 / 1000 / 1000 -> 15 / 30 / 70 / 140 / 250 / 250
Nothing was written; add --apply --backup <dir>.

Częste pytania

Czy za duży asset wywali mi serwer?

Nie. Serwer tylko wysyła plik. Koszt ponosi gra każdego gracza i widać go jako utratę tekstur, brakujące modele i crashe po stronie klienta, częściej na kartach z małą ilością VRAM.

Czy 16 MiB to twarda granica?

Nie, plik na 20 MiB sam zwykle streamuje się dobrze. Kłopot robi wiele za dużych plików w jednym miejscu. 16 MiB na .ytd to budżet, który trzyma cię bezpiecznie na każdej mapie, przy dowolnej liczbie graczy wokół.

Od jakiego rozmiaru FiveM ostrzega o za dużych assetach?

FXServer sprawdza każdy streamowany plik przy starcie jego zasobu i dla każdego pliku powyżej 16 MiB wypisuje Asset <resource>/<file> uses <size> MiB of physical memory., na niebiesko powyżej 16 MiB, na żółto powyżej 32 MiB i na czerwono powyżej 64 MiB. Zdanie „Oversized assets can and WILL lead to streaming issues (such as models not loading/rendering).” dochodzi dopiero powyżej 48 MiB. To samo sprawdzenie dotyczy pamięci wirtualnej pliku i wtedy linijka kończy się na of virtual memory.. Progi znajdziesz w ResourceStreamComponent.cpp FXServera.

A jeśli ostrzeżenie wskazuje plik .yft albo .ydr?

Wtedy tekstury są wbudowane w plik modelu. Stream Optimizer czyta tylko pliki .ytd, więc najpierw przenieś tekstury do osobnego .ytd w OpenIV albo CodeWalkerze albo poproś autora o lżejszą wersję.

Czy gracze muszą coś zrobić?

Nie. Po restarcie zmienione pliki mają nowy hash, więc każdy gracz pobierze mniejszą wersję przy następnym wejściu.

Po optymalizacji przetestuj. Przejedź obok każdej zmienionej mapy i obejrzyj auta z bliska. Jeśli któryś asset wygląda za miękko, przywróć jego oryginał z folderu kopii albo przepuść go jeszcze raz z presetem Lekki.

W którym planie

Stream Optimizer jest w każdym planie, w aplikacji desktopowej i w CLI. Wszystko działa na twoim komputerze, a pliki go nie opuszczają. Asset Doctor jest częścią planu Metro i pilnuje działającego serwera pod kątem nowych za dużych assetów, więc kolejna paczka aut w 4K zostanie złapana, zanim znajdą ją gracze. Porównaj plany albo zobacz wszystkie funkcje.

Wszystkie artykuły