FiveM oversized assets: reduce los .ytd sin perder calidad

Arrancas tu servidor de FiveM y la consola se llena de avisos como este: “Asset … uses 76.0 MiB of physical memory. Oversized assets can and WILL lead to streaming issues (such as models not loading/rendering).” La mayoría de owners lo ignora, porque el servidor funciona. Luego los jugadores empiezan a avisar de carreteras que se vuelven una papilla borrosa, edificios que nunca cargan, coches que aparecen como cajas grises. Es el aviso haciéndose realidad. Esta guía explica qué significa el mensaje, cuánto es demasiado y cómo reducir los texture dictionaries .ytd sobredimensionados sin que tus mapas y coches se vean peor.

Qué significa el aviso

Así se ve el mensaje en la consola del servidor. Los nombres de tus resources serán distintos:

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.

Léelo de izquierda a derecha:

• example_resource es el resource que hace el streaming del archivo, la carpeta dentro de tu directorio resources.
• example_props_txd.ytd es el archivo en sí. Un .ytd es un texture dictionary: un paquete de imágenes que el juego pinta sobre los modelos. Los archivos +hi.ytd contienen las texturas de alto detalle de un vehículo.
• 76.0 MiB of physical memory es la memoria gráfica (VRAM) que ocupa el archivo una vez cargado. No es su tamaño en disco, y suele ser mayor.

El servidor imprime la línea cuando arranca un resource, así que te avisa del problema antes de que ningún jugador lo vea. El archivo sigue haciendo streaming. FiveM solo te advierte de que cada jugador que se acerque tendrá que cargar ahora 76 MiB de una pieza.

Por qué los oversized assets rompen el streaming

GTA V se diseñó para cargar el mundo en trozos pequeños según te mueves. Mantiene un pool de memoria limitado para lo que te rodea y no deja de meter y sacar cosas de él. Un solo texture dictionary de 76 MiB ocupa por sí solo buena parte de ese pool. Cuando varios coinciden en la misma zona del mapa, al juego se le acaba el sitio y empieza a soltar cosas que todavía necesita. Los jugadores lo ven así:

• Pérdida de texturas, también llamada city bug: carreteras, paredes y suelo se ven en baja resolución o borrosos y se quedan así.
• Modelos que no cargan ni se renderizan: edificios, props o interiores que nunca aparecen o lo hacen segundos tarde.
• Coches sin texturas o solo con su modelo de bajo detalle, sobre todo en un garaje o en un car meet con mucha gente.
• Tirones y pantallas de carga largas, porque los archivos grandes tardan más en descargarse, leerse y subirse a la tarjeta gráfica.

Los jugadores con mucha VRAM lo notan más tarde que los que tienen una tarjeta de 4 GB, así que el mismo servidor puede verse bien para el owner y roto para la mitad de los jugadores.

Physical memory frente a virtual memory

Cada archivo de GTA V en streaming se divide en dos partes. La memoria virtual guarda la estructura: nombres, formatos, la lista de texturas. La memoria physical guarda los datos de píxeles en bruto que van a la tarjeta gráfica. En un .ytd, casi todo el peso es physical, y ese es el número del que avisa FiveM.

¿Cuánto es demasiado?

El objetivo habitual, con el que trabajan la mayoría de desarrolladores de FiveM, es 16 MiB de physical memory por asset. Por debajo, FiveM calla. Por encima sale el aviso, y cuanto más te pases, más probables son los problemas de arriba. 16 MiB no es un muro, pero tómalo como presupuesto para cada .ytd.

El tamaño de una textura en memoria depende solo de tres cosas: su resolución, su formato y sus niveles de mip. La tabla muestra una textura con su cadena de mips completa:

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

Así, una sola textura 4096×4096 en DXT5 ya cuesta 21,3 MiB, más que todo el presupuesto. Un pack de mapa con tres de ellas, un par de normal maps y algunas texturas de remate cae justo en los 76 MiB del ejemplo. Una textura 4K sin comprimir es peor aún, con 85,3 MiB ella sola. La mayoría de los oversized assets son simplemente texturas 4K que nadie necesitaba en 4K.

Encuentra todos los oversized assets de tu servidor

La consola solo muestra el aviso mientras arranca el servidor, mezclado con todo lo demás, y es fácil perder alguno. Tienes dos opciones mejores.

1. Busca MiB of physical memory en el log de la consola. Cada coincidencia nombra el resource y el archivo. Buscar Oversized assets se deja los archivos entre 16 y 48 MiB, cuya línea termina tras el tamaño.
2. Deja que lo haga Asset Doctor. Lee cada resource de tu servidor a través del resource de FiveDock y lista cada texture dictionary de más de 16 MiB, con su memoria gráfica junto a su tamaño en disco.

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 también marca los modelos que hacen streaming en dos packs y los resources que nunca arrancan, así que un solo escaneo cubre los motivos habituales por los que un mapa o un coche sale mal. Si dos packs traen el mismo archivo de mapa, la guía de conflictos de mapas explica qué rompe eso.

Reduce las texturas .ytd sin perder calidad

Cada textura de un .ytd está guardada varias veces: a tamaño completo, luego a la mitad, a un cuarto, a un octavo y así hasta unos pocos píxeles. Esas copias son los niveles de mip. El juego elige el nivel que corresponde al tamaño de la superficie en pantalla. Una pared a 20 metros recibe un mip pequeño, y el de tamaño completo solo se usa cuando pegas la cara a ella.

Eso te da una forma de reducir una textura sin tocar sus píxeles: quitar los niveles de mip más grandes. Una textura de 4096×4096 sin sus dos primeros niveles pasa a ser de 1024×1024, con exactamente los píxeles que el juego ya mostraba desde cualquier distancia normal. No se redimensiona, recomprime ni recodifica nada, así que no aparece desenfoque nuevo ni artefactos de bloques. Cada nivel que quitas reduce la memoria a más o menos una cuarta parte.

Ten en cuenta cuánta pantalla hay. En un monitor de 1920×1080, ni una pared que ocupe toda la vista muestra más de unos 2000 píxeles de ancho, así que una textura 4K en una farola o en la puerta de un coche es memoria gastada en un detalle que ningún jugador ve.

La forma manual y su pega

Sin herramienta, la solución es así:

1. Abre el .ytd en OpenIV o CodeWalker y exporta todas las texturas.
2. Redimensiona las grandes en un editor de imágenes.
3. Vuelve a guardarlas como DDS, eligiendo el formato DXT correcto y generando mip maps nuevos.
4. Impórtalas de nuevo, guarda el .ytd y reinicia.

Funciona, pero al guardar en DXT la imagen se comprime por segunda vez, y cada pasada añade artefactos, sobre todo en normal maps y texto. En un servidor con unos cientos de coches y una docena de mapas, además, son días de trabajo.

Redúcelas con el Stream Optimizer

El Stream Optimizer de la app de escritorio de FiveDock aplica el truco de los niveles de mip a todos los .ytd de una carpeta a la vez. Recorta las texturas sobredimensionadas hasta el mayor nivel de mip que cabe en tu límite y deja el resto de los datos de píxeles byte por byte como estaban.

1. Abre Optimizador de stream en la app de escritorio y elige un resource, o toda tu carpeta resources.
2. Elige un preajuste (mira abajo) y una carpeta para los originales.
3. Pulsa Escanear. Verás cada archivo que cambiaría, cada textura con su tamaño antes y después, y cuánta memoria de juego ahorras.
4. Pulsa Optimizar y reinicia el servidor.

Lo mismo desde la línea de comandos, con el archivo del aviso de arriba:

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

Un escaneo no escribe nada. Añade --apply --backup <dir> para escribir los archivos más pequeños y guardar los originales en esa carpeta. En este ejemplo el archivo pasa de 76,0 MiB a 12,0 MiB, por debajo del presupuesto de 16 MiB, y el aviso desaparece en el siguiente arranque.

Qué preajuste elegir

• Seguro no redimensiona nada. Solo arregla las texturas script_rt comprimidas, de las que FiveM también avisa.
• Ligero mantiene las texturas hasta 2048 px. Bueno para assets protagonistas que los jugadores miran de cerca, como un concesionario o un cartel de menú.
• Equilibrado mantiene las texturas hasta 1024 px. Es el predeterminado y la opción correcta para la mayoría de mapas, props y coches.
• Rendimiento mantiene las texturas hasta 512 px. Para props de fondo y servidores cuyos jugadores usan tarjetas gráficas más antiguas.

Empieza con Equilibrado, pasa conduciendo por lo que ha cambiado y sube a Ligero en los pocos assets donde notes diferencia.

Lo que nunca toca

• Los render targets (script_rt_* y scr_*) mantienen su tamaño, porque los scripts dibujan en ellos a una resolución exacta. Los comprimidos se convierten en texturas sin comprimir del mismo tamaño, como exige FiveM.
• Las texturas emisivas: los nombres con emis, glow, neon o que acaban en _em mantienen su tamaño, porque los patrones de luz y los carteles de neón delatan cada píxel perdido.
• Las texturas que ya están por debajo del límite y todo lo que esté en un formato que no conoce se quedan exactamente como están.

Baja los lodDistances de los coches addon

En los vehículos, las texturas son solo la mitad de la historia. Cada coche de vehicles.meta tiene una lista lodDistances: las distancias, en metros, a las que pasa de su modelo de alto detalle a otros más simples, y el último valor es a qué distancia se dibuja como mucho. Muchos coches addon traen valores muy por encima de los del juego base, así que todos los coches de una calle con mucho tráfico se mantienen a detalle completo, +hi.ytd incluido, desde cientos de metros.

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

Marca Optimizar distancia LOD en el Stream Optimizer, o pasa --lod en la línea de comandos. Cada valor baja como mucho a 15, 30, 70, 140, 250 y 250 metros, cerca del juego base. Un valor que ya es más bajo nunca se sube, y solo cambian los números del archivo.

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

Preguntas frecuentes

¿Un oversized asset puede crashear mi servidor?

No. El servidor solo envía el archivo. El coste lo paga el juego de cada jugador, y se nota como pérdida de texturas, modelos que faltan y crashes en el cliente, más a menudo en tarjetas con poca VRAM.

¿Son 16 MiB un límite estricto?

No, un archivo de 20 MiB suele hacer streaming bien por sí solo. El problema llega con muchos archivos sobredimensionados en un mismo sitio. 16 MiB por .ytd es el presupuesto que te mantiene a salvo en cualquier mapa, con cualquier número de jugadores alrededor.

¿A partir de qué tamaño avisa FiveM de los oversized assets?

FXServer revisa cada archivo en streaming cuando arranca su resource e imprime Asset <resource>/<file> uses <size> MiB of physical memory. para cualquier archivo de más de 16 MiB, en azul por encima de 16 MiB, en amarillo por encima de 32 MiB y en rojo por encima de 64 MiB. La frase “Oversized assets can and WILL lead to streaming issues (such as models not loading/rendering).” solo se añade pasados los 48 MiB. La misma comprobación se hace con la virtual memory de un archivo, y entonces la línea termina en of virtual memory.. Los umbrales están en el ResourceStreamComponent.cpp de FXServer.

¿Y si el aviso nombra un archivo .yft o .ydr?

Entonces las texturas están incrustadas en el archivo del modelo. El Stream Optimizer solo lee archivos .ytd, así que primero mueve las texturas a un .ytd aparte con OpenIV o CodeWalker, o pide al autor una versión más ligera.

¿Tienen que hacer algo los jugadores?

No. Tras reiniciar, los archivos modificados tienen un hash nuevo, y cada jugador descarga la versión más pequeña la próxima vez que entre.

Qué plan lo incluye

El Stream Optimizer está en todos los planes, en la app de escritorio y en el CLI. Todo corre en tu máquina y tus archivos nunca salen de ella. Asset Doctor forma parte del plan Metro y vigila tu servidor en vivo por si aparecen nuevos oversized assets, para que el siguiente pack de coches en 4K se detecte antes de que lo encuentren tus jugadores. Compara los planes o mira todas las funciones.