FiveM Oversized Assets: .ytd verkleinern ohne Qualitätsverlust

Du startest deinen FiveM-Server, und die Konsole füllt sich mit Warnungen wie dieser: „Asset … uses 76.0 MiB of physical memory. Oversized assets can and WILL lead to streaming issues (such as models not loading/rendering).“ Die meisten Owner ignorieren das, weil der Server ja läuft. Dann melden Spieler Straßen, die zu verschwommenem Matsch werden, Gebäude, die nie laden, und Autos, die als graue Kisten auftauchen. Das ist die Warnung, die wahr wird. Diese Anleitung erklärt, was die Meldung bedeutet, wie groß zu groß ist und wie du übergroße .ytd-Texture-Dictionaries verkleinerst, ohne dass deine Maps und Autos schlechter aussehen.

Was die Warnung bedeutet

So sieht die Meldung in der Server-Konsole aus. Deine Resource-Namen sehen anders aus:

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.

Lies sie von links nach rechts:

• example_resource ist die Resource, die die Datei streamt, also der Ordner in deinem resources-Verzeichnis.
• example_props_txd.ytd ist die Datei selbst. Eine .ytd ist ein Texture Dictionary: ein Paket aus Bildern, die das Spiel auf Modelle legt. In +hi.ytd-Dateien liegen die hochauflösenden Texturen eines Fahrzeugs.
• 76.0 MiB of physical memory ist der Grafikspeicher (VRAM), den die Datei belegt, sobald sie geladen ist. Das ist nicht die Größe auf der Platte, und meistens ist es mehr.

Der Server gibt die Zeile aus, wenn eine Resource startet, du erfährst vom Problem also, bevor ein Spieler es sieht. Die Datei wird trotzdem gestreamt. FiveM warnt dich nur davor, dass jeder Spieler in der Nähe jetzt 76 MiB am Stück laden muss.

Warum Oversized Assets das Streaming kaputt machen

GTA V streamt die Welt in kleinen Stücken, während du dich bewegst. Es hält einen begrenzten Speicherpool für deine Umgebung bereit und tauscht ständig Inhalte ein und aus. Ein einziges Texture Dictionary mit 76 MiB nimmt allein einen großen Teil dieses Pools. Liegen mehrere davon im selben Kartenbereich, geht dem Spiel der Platz aus, und es wirft Dinge raus, die es noch braucht. Spieler sehen das so:

• Texturverlust, auch City-Bug genannt: Straßen, Wände und Boden werden niedrig aufgelöst oder verschwommen und bleiben so.
• Modelle, die nicht laden oder rendern: Gebäude, Props oder Interiors, die nie erscheinen oder erst Sekunden zu spät aufpoppen.
• Autos ohne Texturen oder nur mit dem Low-Detail-Modell, besonders in einer vollen Garage oder auf einem Car Meet.
• Ruckler und lange Ladebildschirme, weil große Dateien länger zum Herunterladen, Lesen und Hochladen auf die Grafikkarte brauchen.

Spieler mit viel VRAM merken es später als Spieler mit einer 4-GB-Karte. Derselbe Server kann dem Owner also gut aussehen und der Hälfte der Spieler kaputt.

Physical Memory und Virtual Memory

Jede gestreamte GTA-V-Datei besteht aus zwei Teilen. Virtual Memory enthält die Struktur: Namen, Formate, die Liste der Texturen. Physical Memory enthält die rohen Pixeldaten, die an die Grafikkarte gehen. Bei einer .ytd liegt fast das gesamte Gewicht im Physical Memory, und genau diese Zahl meldet FiveM.

Wie groß ist zu groß?

Das übliche Ziel, an dem sich die meisten FiveM-Entwickler orientieren, sind 16 MiB Physical Memory pro Asset. Darunter bleibt FiveM still. Darüber kommt die Warnung, und je weiter du darüber liegst, desto wahrscheinlicher werden die Probleme von oben. 16 MiB sind keine harte Grenze, aber sieh sie als Budget für jede .ytd.

Wie groß eine Textur im Speicher ist, hängt nur von drei Dingen ab: Auflösung, Format und Mip-Leveln. Die Tabelle zeigt eine Textur mit der vollen Mip-Kette:

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

Eine einzige 4096×4096-DXT5-Textur kostet also schon 21,3 MiB, mehr als das ganze Budget. Ein Map-Pack mit dreien davon, ein paar Normal Maps und etwas Trim landet genau bei den 76 MiB aus dem Beispiel oben. Eine unkomprimierte 4K-Textur ist mit 85,3 MiB allein noch schlimmer. Die meisten Oversized Assets sind schlicht 4K-Texturen, die niemand in 4K gebraucht hat.

Alle übergroßen Assets auf deinem Server finden

Die Konsole zeigt die Warnung nur beim Serverstart, zwischen allem anderen, und man übersieht schnell eine. Es gibt zwei bessere Wege.

1. Durchsuche das Konsolen-Log nach MiB of physical memory. Jeder Treffer nennt Resource und Datei. Eine Suche nach Oversized assets verpasst Dateien zwischen 16 und 48 MiB, deren Zeile nach der Größe endet.
2. Lass Asset Doctor es erledigen. Er liest über die FiveDock-Resource jede Resource auf deinem Server und listet jedes Texture Dictionary über 16 MiB auf, mit dem Grafikspeicher neben der Größe auf der Platte.

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 markiert auch Modelle, die zwei Packs streamen, und Resources, die nie starten. Ein Scan deckt also die üblichen Gründe ab, warum eine Map oder ein Auto falsch aussieht. Wenn zwei Packs dieselbe Map-Datei mitbringen, erklärt die Anleitung zu Map-Konflikten, was dadurch kaputtgeht.

.ytd-Texturen verkleinern ohne Qualitätsverlust

Jede Textur in einer .ytd ist mehrfach gespeichert: in voller Größe, dann halb, ein Viertel, ein Achtel und so weiter bis auf ein paar Pixel. Diese Kopien sind die Mip-Level. Das Spiel nimmt das Level, das zur Größe der Fläche auf dem Bildschirm passt. Eine Wand in 20 Metern Entfernung bekommt ein kleines Mip, das volle wird nur benutzt, wenn du mit der Nase davor stehst.

Damit kannst du eine Textur verkleinern, ohne ihre Pixel anzufassen: die größten Mip-Level weglassen. Eine 4096×4096-Textur ohne ihre oberen zwei Level wird zu einer 1024×1024-Textur, deren Pixel genau die sind, die das Spiel aus jeder normalen Entfernung ohnehin gezeigt hat. Nichts wird skaliert, neu komprimiert oder neu kodiert, es entsteht also keine neue Unschärfe und kein Blockrauschen. Jedes entfernte Level senkt den Speicher auf etwa ein Viertel.

Bedenke, wie viel Bildschirm es gibt. Auf einem 1920×1080-Monitor zeigt selbst eine Wand, die das ganze Bild füllt, nie mehr als etwa 2000 Pixel Breite. Eine 4K-Textur auf einem Laternenpfahl oder einer Autotür ist also Speicher für Details, die kein Spieler sieht.

Der manuelle Weg und sein Haken

Ohne Tool sieht der Fix so aus:

1. Öffne die .ytd in OpenIV oder CodeWalker und exportiere alle Texturen.
2. Verkleinere die großen in einem Bildeditor.
3. Speichere sie wieder als DDS, wähle das passende DXT-Format und erzeuge neue Mip Maps.
4. Importiere sie zurück, speichere die .ytd und starte neu.

Das funktioniert, aber beim Speichern als DXT wird das Bild ein zweites Mal komprimiert, und jeder Durchgang fügt Artefakte hinzu, besonders bei Normal Maps und Schrift. Bei einem Server mit ein paar hundert Autos und einem Dutzend Maps sind das außerdem Tage an Arbeit.

Mit dem Stream Optimizer verkleinern

Der Stream Optimizer in der FiveDock-Desktop-App wendet den Mip-Level-Trick auf jede .ytd in einem Ordner auf einmal an. Er kürzt die übergroßen Texturen auf das größte Mip-Level, das in dein Limit passt, und lässt die übrigen Pixeldaten Byte für Byte unverändert.

1. Öffne in der Desktop-App Stream-Optimierer und wähle eine Resource oder deinen ganzen resources-Ordner.
2. Wähle ein Preset (siehe unten) und einen Ordner für die Originale.
3. Klick auf Scannen. Du siehst jede Datei, die geändert würde, jede Textur mit Größe vorher und nachher und wie viel Spielspeicher du sparst.
4. Klick auf Optimieren und starte den Server neu.

Dasselbe über die Kommandozeile, für die Datei aus der Warnung oben:

> 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>.

Ein Scan schreibt nichts. Mit --apply --backup <dir> schreibst du die kleineren Dateien und behältst die Originale in diesem Ordner. In diesem Beispiel sinkt die Datei von 76,0 MiB auf 12,0 MiB, unter das Budget von 16 MiB, und die Warnung ist beim nächsten Start weg.

Welches Preset du nehmen solltest

• Sicher verkleinert nichts. Es repariert nur komprimierte script_rt-Texturen, vor denen FiveM ebenfalls warnt.
• Leicht behält Texturen bis 2048 px. Gut für Hero-Assets, die Spieler aus der Nähe ansehen, etwa ein Autohaus oder ein Menüschild.
• Ausgewogen behält Texturen bis 1024 px. Der Standard und die richtige Wahl für die meisten Maps, Props und Autos.
• Leistung behält Texturen bis 512 px. Für Props im Hintergrund und für Server, deren Spieler ältere Grafikkarten haben.

Fang mit Ausgewogen an, fahr an dem vorbei, was sich geändert hat, und geh bei den wenigen Assets, bei denen dir ein Unterschied auffällt, auf Leicht hoch.

Was er nie anfasst

• Render Targets (script_rt_* und scr_*) behalten ihre Größe, weil Scripts mit exakter Auflösung darauf zeichnen. Komprimierte werden in unkomprimierte Texturen gleicher Größe umgewandelt, wie FiveM es verlangt.
• Emissive Texturen: Namen mit emis, glow, neon oder mit Endung _em behalten ihre Größe, denn Lichtmuster und Neonschilder zeigen jeden verlorenen Pixel.
• Texturen unter dem Limit und alles in einem unbekannten Format bleiben genau, wie sie sind.

lodDistances bei Addon-Autos senken

Bei Fahrzeugen sind Texturen nur die halbe Geschichte. Jedes Auto in der vehicles.meta hat eine lodDistances-Liste: die Entfernungen in Metern, ab denen es vom hochdetaillierten Modell auf einfachere umschaltet, und der letzte Wert ist, wie weit es überhaupt gezeichnet wird. Viele Addon-Autos bringen Werte weit über dem Basisspiel mit, sodass jedes Auto auf einer vollen Straße schon aus hunderten Metern in voller Detailstufe gehalten wird, samt +hi.ytd.

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

Hak im Stream Optimizer LOD-Distanz optimieren an oder übergib --lod auf der Kommandozeile. Jeder Wert wird auf höchstens 15, 30, 70, 140, 250 und 250 Meter gesenkt, nah am Basisspiel. Ein Wert, der schon niedriger ist, wird nie erhöht, und nur die Zahlen in der Datei ändern sich.

> 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>.

Häufige Fragen

Crasht ein Oversized Asset meinen Server?

Nein. Der Server schickt die Datei nur. Den Preis zahlt das Spiel jedes Spielers, und er zeigt sich als Texturverlust, fehlende Modelle und Crashes auf dem Client, öfter bei Karten mit wenig VRAM.

Sind 16 MiB eine harte Grenze?

Nein, eine Datei mit 20 MiB streamt allein meist problemlos. Der Ärger entsteht durch viele übergroße Dateien an einer Stelle. 16 MiB pro .ytd ist das Budget, mit dem du auf jeder Map und bei beliebig vielen Spielern in der Nähe sicher bist.

Ab welcher Größe warnt FiveM vor Oversized Assets?

FXServer prüft jede gestreamte Datei beim Start ihrer Resource und gibt für jede Datei über 16 MiB Asset <resource>/<file> uses <size> MiB of physical memory. aus, in Blau über 16 MiB, in Gelb über 32 MiB und in Rot über 64 MiB. Der Satz „Oversized assets can and WILL lead to streaming issues (such as models not loading/rendering).“ kommt erst ab 48 MiB dazu. Dieselbe Prüfung läuft für den Virtual Memory einer Datei, und die Zeile endet dann auf of virtual memory.. Die Schwellenwerte stehen in FXServers ResourceStreamComponent.cpp.

Was, wenn die Warnung eine .yft- oder .ydr-Datei nennt?

Dann stecken die Texturen in der Modelldatei. Der Stream Optimizer liest nur .ytd-Dateien. Verschieb die Texturen also zuerst in OpenIV oder CodeWalker in eine eigene .ytd oder frag den Autor nach einer leichteren Version.

Müssen Spieler etwas tun?

Nein. Nach deinem Neustart haben die geänderten Dateien einen neuen Hash, und jeder Spieler lädt beim nächsten Join die kleinere Version.

Welcher Tarif es hat

Der Stream Optimizer ist in jedem Tarif enthalten, in der Desktop-App und im CLI. Alles läuft auf deinem Rechner, deine Dateien verlassen ihn nie. Asset Doctor gehört zum Tarif Metro und überwacht deinen Live-Server auf neue Oversized Assets, damit das nächste 4K-Car-Pack auffällt, bevor deine Spieler es finden. Tarife vergleichen oder alle Features ansehen.