No empieces aplicando el límite de triángulos de otra persona. Empieza con una prueba repetible. Sin ella, un servidor más tranquilo o un ángulo distinto pueden parecer una optimización correcta.
Es un flujo técnico para tu mapa, no un conjunto de afirmaciones de benchmark sobre CodeWalker o FiveM.
Fija la referencia inicial
Registra versión de assets, equipo cliente, gráficos, resolución, edición de destino y recursos del servidor. Elige puntos fijos: aproximación por la calle, entrada, habitación principal y vista interior más detallada.
Repite la misma ruta varias veces. Registra tiempos de fotograma cuando la herramienta los proporcione y las condiciones de cada prueba. Incluye una aproximación en frío y una visita repetida; no las compares sin identificar la diferencia.
Un cambio solo es útil si la prueba mide lo mismo antes y después. Conserva el paquete original para volver a probarlo directamente.
Separa los factores de coste
Inspecciona geometría, variedad de materiales, tamaño de texturas, complejidad de colisión y contenido visible por las aberturas. Son factores distintos. Reducir uno no demuestra que otro deje de ser un cuello de botella.
Haz una intervención pequeña, como simplificar un objeto decorativo, y repite la ruta. Si la diferencia está dentro de la variación de referencia, regístralo en lugar de inventar una mejora.
En una escena densa puede servir una versión sencilla de diagnóstico. Quita una categoría de decoración opcional en una versión aparte, dejando intactas estructura y colocación. Es un experimento, no la optimización final.
Usa los niveles de detalle de forma deliberada
El README de CodeWalker explica los niveles jerárquicos de detalle de GTA y su relación con la distancia de cámara. También indica que ciertos contenidos detallados requieren el contexto de mapa adecuado cargado en el visor.
Un modelo de poco detalle debe conservar la silueta y los rasgos importantes para su distancia de observación. Revisa la transición desde varias aproximaciones. Una malla menor no es un buen resultado si provoca un salto visual molesto en la entrada.
No corrijas todo problema de visibilidad aumentando la distancia de dibujado. Comprueba antes colocación, límites y jerarquía. Una distancia mayor puede ocultar un error estructural y mostrar más contenido del previsto.
Revisa las texturas observando el asset
Lista tamaños de texturas, contenido repetido y uso real. Una textura grande en un objeto diminuto en pantalla merece revisión, igual que un diccionario de texturas duplicado por accidente.
Haz una sustitución controlada: cambia la resolución de un asset, revísalo a la distancia prevista más cercana y compara las mediciones de la ruta. Conserva la calidad necesaria en lugar de optimizar una cifra aislada.
No confundas el tamaño del ZIP en disco con el uso de memoria en ejecución. Compresión, formatos de texturas y carga afectan a partes distintas del sistema. Informa de lo medido sin sustituir una métrica por otra.
Vuelve a comprobar el grafo interior
Una corrección que muestre todo el interior desde cualquier punto cercano puede tener otro coste que una configuración bien delimitada. Revisa las pruebas de habitaciones y portales tras los cambios estructurales.
No elimines límites útiles para ocultar un fallo de portal. Separa corrección y optimización como criterios: primero debe mostrarse el contenido previsto y después hacerlo bajo las condiciones de rendimiento buscadas.
Publica observaciones, no afirmaciones universales
Una nota útil indica hardware, ajustes, ruta, versiones comparadas y resultado. «Optimizado» sin esos datos dice poco a otro operador.
Termina con la lista de comprobación de publicación. Reconexión, colisión y recursos vecinos siguen importando después de una comparación favorable de tiempos. Una optimización que rompe una puerta no está lista para distribuir.
Usa una hoja de rendimiento repetible
Descarga el CSV vacío de pruebas de rendimiento. Contiene campos, no resultados inventados. Registra edición, versiones del juego/servidor, revisión, CPU/GPU, RAM, resolución, gráficos, clima/hora y una ruta con nombre. Mantén esas condiciones entre referencia y candidato.
Usa una fila por repetición y distingue la carga en frío del recorrido ya cargado. Mide tiempos de fotograma con el mismo método en ambos candidatos; usa el cálculo documentado de mediana y percentil 95. Un tiempo menor es mejor, pero un cambio inferior a la variación entre pruebas no demuestra una mejora convincente.
Comprueba la corrección visual y física junto a los tiempos. Una habitación ausente puede renderizar más rápido precisamente porque falta. Rechaza mejoras aparentes que rompan visibilidad, texturas, colisión o distancia necesaria. Registra cambios de tamaño sin tratarlos por sí solos como medición del rendimiento de la GPU.
Compara un cambio cada vez
Conserva intacta la referencia, cambia un asset o relación y repite la ruta varias veces. Restaura la referencia para comprobar que el efecto venga del candidato y no de la sesión o cámara. Informa de hardware y condiciones sin prometer una ganancia universal de FPS.
Usa la ruta de portales para detectar regresiones de visibilidad y la lista de comprobación de publicación para conservar las evidencias. Una vista previa de representaciones en el navegador no es un benchmark del renderizado de GTA V.