FiveM oversized assets: shrink .ytd textures without quality loss

You start your FiveM server and the console fills up with warnings like this one: "Asset … uses 76.0 MiB of physical memory. Oversized assets can and WILL lead to streaming issues (such as models not loading/rendering)." Most owners ignore it, because the server runs fine. Then players start reporting roads that turn into blurry mush, buildings that never load, cars that show up as grey boxes. That is the warning coming true. This guide explains what the message means, how big is too big, and how to shrink oversized .ytd texture dictionaries without making your maps and cars look worse.

What the warning means

This is what the message looks like in the server console. Your resource names will differ:

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.

Read it from left to right:

• example_resource is the resource that streams the file, the folder in your resources directory.
• example_props_txd.ytd is the file itself. A .ytd is a texture dictionary: a pack of images the game paints onto models. +hi.ytd files hold the high-detail textures of a vehicle.
• 76.0 MiB of physical memory is how much graphics memory (VRAM) the file takes once it is loaded. That is not the size on disk, and it is usually bigger.

The server prints the line when a resource starts, so it tells you about the problem before any player sees it. The file still streams. FiveM is only warning you that every player who gets near it now has to load 76 MiB in one piece.

Why oversized assets break streaming

GTA V was built to stream the world in small pieces as you move. It keeps a limited pool of memory for what is around you and keeps swapping things in and out of it. A single 76 MiB texture dictionary takes a large share of that pool on its own. When several of them sit in the same part of the map, the game runs out of room and starts dropping things it still needs. Players see that as:

• Texture loss, also called the city bug: roads, walls and the ground turn low-res or blurry and stay that way.
• Models not loading or rendering: buildings, props or interiors that never appear, or pop in seconds late.
• Cars without textures or with only their low-detail model, especially in a busy garage or car meet.
• Stutters and long loading screens, since big files take longer to download, read and upload to the graphics card.

Players with a lot of VRAM notice it later than players on a 4 GB card, so the same server can look fine to the owner and broken to half the player base.

Physical memory vs. virtual memory

Every streamed GTA V file is split into two parts. Virtual memory holds the structure: names, formats, the list of textures. Physical memory holds the raw pixel data that goes to the graphics card. For a .ytd, almost all of the weight is physical, and that is the number FiveM warns about.

How big is too big?

The usual target, and the one most FiveM developers work to, is 16 MiB of physical memory per asset. Below it FiveM stays quiet. Past it you get the warning, and the further past it you go, the more likely the problems above become. 16 MiB is not a hard wall, but treat it as your budget for every .ytd.

The size of a texture in memory depends on only three things: its resolution, its format, and its mip levels. The table shows one texture with its full mip chain:

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

So a single 4096×4096 DXT5 texture already costs 21.3 MiB, more than the whole budget. A map pack with three of them, a couple of normal maps and some trim textures lands right at the 76 MiB in the example above. An uncompressed 4K texture is worse still at 85.3 MiB on its own. Most oversized assets are just 4K textures that nobody needed in 4K.

Find every oversized asset on your server

The console only shows the warning while the server starts, mixed in with everything else, and it is easy to miss one. You have two better options.

1. Search the console log for MiB of physical memory. Every match names the resource and the file. A search for Oversized assets misses files between 16 and 48 MiB, whose line ends after the size.
2. Let Asset Doctor do it. It reads every resource on your server through the FiveDock resource and lists every texture dictionary over 16 MiB, with its graphics memory next to its size on disk.

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 also flags the models that two packs both stream and the resources that never start, so one scan covers the usual reasons a map or car shows up wrong. If two packs ship the same map file, the map conflicts guide explains what that breaks.

Shrink .ytd textures without losing quality

Every texture in a .ytd is stored several times: at full size, then at half, a quarter, an eighth and so on down to a few pixels. Those copies are mip levels. The game picks the level that matches how big the surface is on screen. A wall 20 metres away gets a small mip, the full-size one is only used when you press your face against it.

That gives you a way to shrink a texture without touching its pixels: drop the largest mip levels. A 4096×4096 texture with its top two levels removed becomes a 1024×1024 texture whose pixels are exactly the ones the game was already showing from any normal distance. Nothing is resized, re-compressed or re-encoded, so no new blur or blocky artifacts appear. Each level you drop cuts the memory to about a quarter.

Keep in mind how much screen there is. On a 1920×1080 monitor even a wall that fills the whole view never shows more than about 2000 pixels across, so a 4K texture on a lamp post or a car door is memory spent on detail no player can see.

The manual way, and its catch

Without a tool, the fix looks like this:

1. Open the .ytd in OpenIV or CodeWalker and export every texture.
2. Resize the big ones in an image editor.
3. Save them as DDS again, picking the right DXT format and generating new mip maps.
4. Import them back, save the .ytd and restart.

It works, but saving to DXT compresses the image a second time, and every pass adds artifacts, especially on normal maps and text. On a server with a few hundred cars and a dozen maps it is also days of work.

Shrink them with the Stream Optimizer

The Stream Optimizer in the FiveDock desktop app does the mip level trick for every .ytd in a folder at once. It cuts the oversized textures down to the largest mip level that fits your limit and leaves the remaining pixel data byte for byte as it was.

1. Open Stream optimizer in the desktop app and pick a resource, or your whole resources folder.
2. Pick a preset (see below) and a folder for the originals.
3. Click Scan. You see every file it would change, each texture with its size before and after, and how much game memory you save.
4. Click Optimize and restart the server.

The same thing from the command line, for the file from the warning above:

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

A scan writes nothing. Add --apply --backup <dir> to write the smaller files and keep the originals in that folder. In this example the file goes from 76.0 MiB to 12.0 MiB, under the 16 MiB budget, and the warning is gone on the next start.

Which preset to pick

• Safe resizes nothing. It only fixes compressed script_rt textures, which FiveM also warns about.
• Light keeps textures up to 2048 px. Good for hero assets players look at up close, like a showroom or a menu sign.
• Balanced keeps textures up to 1024 px. The default, and the right choice for most maps, props and cars.
• Performance keeps textures up to 512 px. For background props and servers whose players run older graphics cards.

Start with Balanced, drive past what changed, and step up to Light for the few assets where you notice a difference.

What it never touches

• Render targets (script_rt_* and scr_*) keep their size, because scripts draw onto them at an exact resolution. Compressed ones are turned into uncompressed textures of the same size, as FiveM requires.
• Emissive textures: names with emis, glow, neon or ending in _em keep their size, since light patterns and neon signs show every lost pixel.
• Textures already under the limit and anything in a format it doesn’t know stay exactly as they are.

Lower lodDistances on addon cars

Textures are half the story for vehicles. Each car in vehicles.meta has a lodDistances list: the distances, in metres, at which it switches from its high-detail model to simpler ones, and the last value is how far away it is drawn at all. Many addon cars ship with values far above the base game, so every car on a busy street is kept in full detail, +hi.ytd included, from hundreds of metres away.

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

Tick Optimize LOD distance in the Stream Optimizer, or pass --lod on the command line. Every value is lowered to at most 15, 30, 70, 140, 250 and 250 metres, close to the base game. A value that is already lower is never raised, and only the numbers in the file change.

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

Common questions

Will an oversized asset crash my server?

No. The server only sends the file. The cost is paid by every player’s game, and it shows up as texture loss, missing models and crashes on the client side, more often on cards with little VRAM.

Is 16 MiB a hard limit?

No, a 20 MiB file usually streams fine on its own. The trouble comes from many oversized files in one place. 16 MiB per .ytd is the budget that keeps you safe on any map, with any number of players around.

At what size does FiveM warn about oversized assets?

FXServer checks every streamed file when its resource starts and prints Asset <resource>/<file> uses <size> MiB of physical memory. for any file over 16 MiB, in blue above 16 MiB, yellow above 32 MiB and red above 64 MiB. The sentence “Oversized assets can and WILL lead to streaming issues (such as models not loading/rendering).” is only added past 48 MiB. The same check runs on a file’s virtual memory, and that line ends in of virtual memory. instead. The thresholds are in FXServer’s ResourceStreamComponent.cpp.

What if the warning names a .yft or .ydr file?

The textures are then embedded in the model file. The Stream Optimizer reads .ytd files only, so move the textures into a separate .ytd in OpenIV or CodeWalker first, or ask the author for a lighter version.

Do players have to do anything?

No. After you restart, the changed files have a new hash, so every player downloads the smaller version on their next join.

Which plan has it

The Stream Optimizer is on every plan, in the desktop app and the CLI. Everything runs on your machine, and your files never leave it. Asset Doctor is part of the Metro plan and watches your live server for new oversized assets, so the next 4K car pack gets caught before your players find it. Compare the plans or see every feature.