Por qué el rendimiento de 'Cities: Skylines 2' es tan pobre

• Aunque Cities: Skylines 2 es un juego centrado en la simulación, en la mayoría de las situaciones destaca un cuello de botella en la GPU, y hay benchmarks que muestran que para apuntar a 1080p 60FPS incluso con ajustes mínimos o superiores se necesita una tarjeta gráfica del rango de 1000 a 2000 euros
• Un frame de ejemplo capturado con Renderdoc muestra 87.8 ms, 6705 draw calls, más de 50 mil API calls y unos 6.7 GB de uso de buffers y texturas de GPU, muy lejos de los 16.7 ms necesarios para 60FPS
• El núcleo del cuello de botella es la falta de LOD en muchas mallas y un culling simple, lo que hace que se renderice repetidamente geometría de alto poligonaje que casi no contribuye a la imagen; solo el pase de sombras consume 40 ms y representa el 72% de todos los draw calls
• Los polémicos dientes de los ciudadanos sí se renderizan, pero no son la causa única; el problema mayor es la acumulación de conteos de vértices excesivos y renderizado ineficiente en modelos de ciudadanos, props y elementos decorativos en general
• La integración entre Unity DOTS y HDRP aún parece inmadura, y hay indicios de que Colossal Order implementó por su cuenta la conexión entre ECS y el renderer, el culling y el virtual texturing; redujeron los cuellos de botella de CPU, pero el pipeline gráfico todavía no parece suficientemente pulido

---

Problemas de rendimiento evidentes antes y después del lanzamiento

• Desde antes del lanzamiento, Cities: Skylines 2 ya tenía aumento en los requisitos recomendados, retraso de la versión de consolas hasta 2024 y restricciones para hablar del rendimiento
• Una semana antes del estreno, Colossal Order publicó un aviso que rozaba una explicación anticipada de los problemas de rendimiento, y tras el lanzamiento el rendimiento se convirtió en un blanco de crítica casi universal
• Los juegos de construcción de ciudades pueden tener dificultades para alcanzar altos framerates, pero en este caso destaca un cuello de botella de GPU más que el típico cuello de botella de CPU del género
• Según benchmarks de PC Games Hardware y Gamers Nexus, para lograr 1080p 60FPS con ajustes de “very low” o superiores se requiere una GPU de aproximadamente 1000 a 2000 euros
• En un entorno con RTX 3080, Ryzen 7 5800X y monitor 5120×1440, en el primer arranque el menú principal estaba por debajo de 10FPS, y al desactivar depth of field, motion blur y volumetric effects como recomendó el estudio, subió hasta cerca de 90FPS
• En un mapa vacío se obtuvieron unos 30 a 40FPS, y después de jugar alrededor de una hora se mantuvo un nivel similar con tirones ocasionales

Motor y estructura de renderizado

• Cities: Skylines 2 está basado en Unity 2022.3.7 y utiliza DOTS, ECS y el Burst compiler de Unity
• Gracias a DOTS, parece usar muchos núcleos de CPU con mucha más eficiencia que la entrega anterior
• La lógica del juego está compuesta en el código por unos 1200 sistemas, y parece que prácticamente toda la lógica real del juego está montada sobre una estructura ECS
• La UI no usa Unity UI Toolkit, sino Coherent Gameface basado en HTML, CSS y JavaScript
  • En los bundles de JS hay rastros del uso de React y Webpack
  • La UI puede tener ventajas en mantenimiento y facilidad de cambios, pero según los datos analizados no es el cuello de botella principal
• Los gráficos usan Direct3D 11 y HDRP de Unity
• Para conectar un juego hecho con DOTS/ECS al sistema de renderizado tradicional de Unity se necesita una capa adicional, pero Cities: Skylines 2 aparentemente no usa Unity Entities Graphics
  • El skinning y el occlusion culling de Entities Graphics están marcados como experimentales
  • No hay soporte para virtual texturing
  • En su lugar, parece que implementaron una capa propia usando BatchRendererGroup y código de bajo nivel

Entorno de análisis con Renderdoc y sus límites

• Para el análisis de renderizado se utilizó Renderdoc
• La versión de Game Pass no permitía que Renderdoc ni NVidia Nsight Graphics accedieran al ejecutable por problemas de sandboxing o permisos de archivos
• En la versión de Steam también fue difícil conectarse con Renderdoc por el Paradox Launcher y el flujo de autenticación de Steam, y al final se logró la captura usando el Global Process Hook de Renderdoc
• NVidia Nsight Graphics funcionó abriendo Steam desde Nsight y lanzando el juego desde ahí, pero en D3D11 muchas funciones de profiling no están soportadas, así que no ofreció mucha más información que Renderdoc
• El frame analizado fue capturado en una ciudad de alrededor de 1000 habitantes
  • La versión del juego era 1.0.11f1
  • El parche más reciente, 1.0.12f1, incluye algunas mejoras, pero no resuelve todos los problemas
  • El tiempo de frame medido por Renderdoc fue de 87.8 ms, equivalente a unos 11.4FPS
  • Como durante el gameplay real el promedio era de 30 a 40FPS, podría haber overhead de Renderdoc o tratarse de un frame atípico

Métricas de renderizado del frame de ejemplo

• Las estadísticas del frame de ejemplo reportadas por Renderdoc fueron las siguientes
  • Draw calls: 6705
  • Dispatch calls: 191
  • API calls: 53361
  • Index/vertex bind calls: 8724
  • Constant bind calls: 25006
  • Resource update calls: 1679
  • Textures: 342, unos 3926MB
  • Render targets: 180, unos 2328MB
  • Buffers: 4144, unos 447MB
  • Total de buffers y texturas de GPU: unos 6.7GB
• Un uso de 6.7GB de VRAM es alto para una escena relativamente simple, y todavía existen GPUs de gama media de la generación actual con 8GB de VRAM
• Según un análisis adicional en la FAQ, renderizar ese frame implicó 121 millones de input vertices y unos 36 millones de rasterized triangles
  • Eso no representa el total de polígonos realmente visibles en pantalla, sino toda la geometría procesada en todos los pases de render
  • En Reddit también hay reportes de cientos de millones de vértices en ciudades más grandes, e incluso hasta 1000 millones de vértices por frame en ciertas situaciones

Instancing de DOTS y actualización de datos en GPU

• Casi todos los draw calls usan instancing
• El juego guarda en un gran buffer único los datos de instancia necesarios para renderizar todos los objetos
• Los objetos normales parecen usar unos 50 float por instancia, y las carreteras usan todavía más datos
• Los datos de instancia de todos los objetos visibles se actualizan en ese buffer en cada frame y se suben a la GPU
• El buffer empieza alrededor de 60MB y se reasigna a un tamaño mayor si hace falta
• Ese buffer se usa en casi todos los draw calls y, según Renderdoc, está accesible desde el vertex shader y el pixel shader
• Eso puede implicar un costo de consulta del buffer para todos los vértices y combinarse con el problema de las mallas de alto poligonaje

Simulación y virtual texturing

• Los compute shaders de GPU se usan para simulaciones relacionadas con gráficos como agua, nieve, partículas y animación esquelética
• En conjunto, estas tareas consumen alrededor de 1.5 ms, menos del 2% del tiempo total del frame
• Las primeras suposiciones de que el juego descargaba masivamente su simulación real a la GPU no coinciden con el código decompilado ni con las llamadas observadas en la GPU
• Cities: Skylines 2 parece implementar su propio sistema de virtual texturing / texture streaming
  • El Streaming Virtual Texturing integrado de Unity sigue en estado experimental o no soportado
  • El juego parece usar virtual texturing en la mayoría de los objetos 3D estáticos, excepto el terreno
• El virtual texturing puede ahorrar memoria cargando solo los tiles necesarios, pero en la implementación actual existe el problema de que ni siquiera en superficies cercanas se cargan texturas de alta resolución
• La falta de soporte para anisotropic texture filtering también podría estar relacionada con el uso de virtual texturing
• Ese pase toma alrededor de 0.5 ms

Costo por los principales pases de renderizado

• Skybox generation

  • Usa el sistema de cielo físico de Unity HDRP para generar un cubemap en cada frame
  • Toma unos 0.65 ms, casi el 4% del presupuesto de frame para 60FPS

• Pre-pass

  • Es la primera etapa del deferred rendering y escribe en texturas separadas la información estimada de depth, normal y smoothness
  • Toma unos 8.2 ms, lo que lo vuelve muy pesado

• Motion vectors

  • Renderiza en un pase separado los motion vectors por píxel usados para anti-aliasing y motion blur
  • Toma unos 0.6 ms
  • Los motion vectors parecen estar parcialmente rotos, y por eso al momento de escribir el artículo no había soporte para DLSS ni FSR2

• Roads and decals

  • Renderiza carreteras, pasto y elementos que se adhieren a la superficie del terreno
  • Toma alrededor de 1 ms

• Main pass

  • Es el pase central del deferred rendering y usa los buffers previos y la caché de virtual texturing para generar albedo, normal, propiedades PBR, depth, etc.
  • Aquí también se genera la información de visibilidad del virtual texturing
  • Aparentemente se renderiza a la mitad de la resolución horizontal, mientras que el terreno no usa virtual texturing y sí se renderiza a resolución completa
  • Toma unos 16.7 ms, lo mismo que todo el tiempo disponible por frame a 60FPS

• Ambient occlusion

  • Según el nombre de debug del shader, parece usar GTAO
  • Toma unos 1.6 ms

• SSR + SSGI

  • Usa screen space reflections y screen space global illumination de Unity HDRP
  • Ambos efectos juntos consumen unos 3 ms

• Deferred lighting

  • Combina los buffers intermedios generados antes para producir un resultado ya muy cercano a la imagen final
  • Toma unos 2.1 ms

• Water rendering

  • Renderiza el agua usando preprocesado con compute shaders e imágenes reducidas y desenfocadas como entrada
  • Toma alrededor de 1 ms

• Post-processing

  • Usa temporal AA, bloom, tonemapping y, si están activados, DOF y motion blur
  • Todo ello consume unos 1 a 2 ms

• UI

  • Renderiza la UI basada en Gameface y el texto dentro del mundo
  • Los nombres de calles se renderizan con signed distance fields 2D y usan el depth buffer para mezclarse con la escena cuando quedan detrás de edificios
  • El tiempo del pase final de UI es prácticamente despreciable

La polémica de los dientes y los modelos de personajes

• Los personajes ciudadanos sí tienen un modelo de dientes completo y en la vista normal del juego no se ve
• A raíz del análisis de NVidia Nsight Graphics hecho por el usuario de Reddit Hexcoder0, se supo que los dientes siempre se renderizan con la máxima calidad
• El problema más importante es que las mallas relacionadas con los personajes en general no tienen variantes LOD
• Colossal Order reconoció públicamente este problema y también mencionó un problema más amplio de manejo de LOD
• Los modelos de ciudadanos se generan con base en Didimo Popul8, y el modelo de dientes/boca del juego tiene 6108 vertices, más que los 1060 vertices de la malla base de Didimo
• Un solo personaje, sin contar cabello, ropa ni accesorios, llega a unos 56 mil vertices
  • Un edificio residencial promedio de baja densidad, sin incluir props del patio ni otros detalles, tiene menos de 10 mil vertices
• En el frame de ejemplo se renderizan 13 juegos de dientes, pero no afectan ni un solo píxel de la imagen final
• Más que ser la causa única de la caída de rendimiento, los dientes son una prueba de que hay mucha geometría innecesaria de alto poligonaje presente en todo el juego

Props de alto poligonaje y problemas de culling

• El juego renderiza demasiados objetos con un conteo de polígonos demasiado alto aun cuando aportan muy poco o nada a la imagen final
• Las causas principales son dos
  • Algunos modelos no tienen variantes LOD
  • Su sistema propio de culling es simple y parece implementar solo frustum culling, sin rastros de occlusion culling
• Sí existe culling por distancia, pero no es agresivo, así que reduce el pop-in a costa del rendimiento
• Algunos props de alto poligonaje confirmados en el análisis son los siguientes
  • Pallet de cilindros de gas: más de 17 mil vertices
  • Tendedero: 25 mil vertices por unidad, y la variante más densa supera los 30 mil vertices
  • Caseta de estacionamiento: más de 40 mil vertices, sin LOD, con cables individuales modelados incluso para el monitor y el teclado
  • Pila de troncos: más de 100 mil vertices
• Combinar edificios y props interiores en una sola malla reduce draw calls, pero impide hacer culling individual de los props internos
• En un city builder, el mismo modelo ineficiente puede renderizarse cientos de veces en un mismo frame, así que pequeños desperdicios terminan acumulándose
• El problema no es que existan modelos de alta resolución en sí, sino que el juego no puede sostener ese nivel de detalle y el uso de polígonos es ineficiente e inconsistente

El pase de sombras es el mayor cuello de botella

• Cities: Skylines 2 usa cascaded shadow mapping
• Las sombras tienen muchos artifacts y flickering, especialmente cuando se mueven el sol o las hojas de los árboles
• El juego usa 4 cascades y la resolución por cascade es de 2048×2048
• Existe una opción de gráficos avanzados para la resolución del directional shadow map, pero en el código al momento del análisis no estaba conectada
  • Ni esa opción individual ni la configuración global de shadow quality cambian la resolución del shadow map
  • Los presets medium y high de sombras son en la práctica iguales
  • El preset low desactiva las sombras proyectadas por el terreno
• A pesar de su baja calidad, el shadow mapping es el pase de render más lento con unos 40 ms
• De los 6705 draw calls del frame de ejemplo, 4828, es decir el 72%, se usan en shadow mapping
• Parece que el juego trata todos los objetos 3D como posibles shadow casters sin importar su tamaño o distancia, en todas las configuraciones de calidad
• En los contadores de rendimiento de Renderdoc, muchos draw calls solo afectan entre 0 y 100 píxeles del shadow map, y los dientes también reaparecen en el pase de sombras
• Mejorar LOD y culling podría impactar mucho también en el rendimiento del shadow mapping
• Como detalle positivo, el juego calcula la posición del sol y la luna usando la fecha, hora y coordenadas actuales de la ciudad

Problemas de rendimiento en el menú principal

• El menú principal parece mostrar solo una imagen de fondo estática y botones, pero en realidad siempre existe una escena 3D
• Detrás del menú se renderiza una escena con terreno, agua y skybox, y luego la UI la cubre por completo
• Como se usa todo el pipeline de renderizado incluso para una escena no visible, los ajustes gráficos afectan de inmediato el rendimiento del menú principal
• En el lanzamiento, la mayoría de las configuraciones venían por defecto cerca del máximo, incluyendo efectos pesados que el propio estudio recomendó desactivar
• Aun así, la causa exacta de la caída hasta unos 7FPS en el primer arranque no está del todo aclarada
  • Ese mismo nivel de degradación ya no se pudo reproducir después
  • En el primer inicio se procesan tareas relacionadas con la caché de virtual texturing, pero no se confirmó si usan la GPU
• Toda la escena del menú principal contiene alrededor de 400 draw calls, 563 mil input vertices y 745 mil rasterized triangles

Aclaraciones complementarias de la FAQ

• No es fácil afirmar que debió haberse hecho en Unreal Engine 5
  • UE5 tiene Nanite, Lumen y Virtual Shadow Maps, que podrían abordar algunos de los problemas que sufre C:S2
  • Pero le faltan funciones de nivel de producción equivalentes a Unity ECS para lógica masiva de juego y simulación, y su estructura centrada en C++ podría ser menos flexible y accesible para el modding
• El juego no carece por completo de LOD
  • Muchos edificios sí parecen tener LOD adecuados
  • Pero en elementos como tuberías, props de patio y decoraciones hay muchos casos sin LOD o donde no se elige correctamente
• InstaLOD parece usarse en el asset pipeline del juego, especialmente al importar nuevos assets en la herramienta de mods, y no en el renderizado en tiempo real
• La UI basada en JavaScript no es el cuello de botella principal según los datos analizados
  • Gameface no está basado en un motor de navegador completo como Electron, sino en un framework personalizado para UI de juegos
  • Se dice que debería tener ventajas en uso de memoria y rendimiento frente a soluciones basadas en Chromium/Blink o WebKit
• Renderdoc tiene limitaciones como herramienta de benchmark preciso, pero sí ofrece evidencia suficiente para entender “qué hace el juego para ser tan lento”

Conclusión: se redujo el cuello de botella de CPU, pero el pipeline de GPU está casi sin terminar

• La razón directa de que Cities: Skylines 2 sea excesivamente pesado para la GPU es que envía demasiada geometría innecesaria a la tarjeta gráfica
• Ese desperdicio de geometría proviene de la falta de LOD en muchas mallas y de una implementación de culling simple y poco ajustada
• La razón de implementar una capa propia de culling y conexión con el renderer parece ser que la integración entre Unity DOTS y HDRP aún está en desarrollo y tenía demasiadas limitaciones para usarse en un juego real
• El virtual texturing de Unity también sigue en estado experimental, por lo que Colossal Order implementó su propia solución, y ese sistema también muestra partes todavía inmaduras
• La interpretación más plausible es que Colossal Order apostó por nuevas tecnologías de Unity como DOTS y consiguió avances en cuellos de botella de CPU y escala de simulación, pero a cambio tuvo que implementar por su cuenta sistemas como culling, animación y texture streaming en el apartado gráfico
• La afirmación del estudio de que el juego apuntaba a 30FPS desde el inicio resulta poco creíble según esta evaluación, y considerando que es un juego solo para PC y su calidad gráfica, no parece una justificación válida del objetivo de rendimiento
• Las áreas con mayor potencial de mejora son agregar LOD, mejorar el culling, optimizar la selección de shadow casters y depurar los assets a nivel de props, aunque podría tomar tiempo porque quizá haya que retocar muchos assets de forma individual

[GN⁺]

Comentarios de Hacker News

• Es un artículo interesante, así que ojalá la discusión se centrara en qué es exactamente lo interesante
  Este tipo de hilos tiende fácilmente a derivar en generalidades sobre $THING en sí, aquí el juego en general, o sobre $RELATED, aquí el framework, o sobre objetos similares en general
  En principio no está mal, pero con cada paso hacia la generalidad la discusión se vuelve más superficial y menos interesante. Por eso en las guías del sitio también aparece “evita las discusiones generales tangenciales” - https://news.ycombinator.com/newsguidelines.html

• La parte que dice que “la razón por la que Colossal Order no usa el culling integrado de Unity y tiene su propia implementación es que la integración de Unity con DOTS y HDRP todavía está en pleno proceso, y puede considerarse inadecuada para la mayoría de los juegos reales, así que tuvieron que implementar por su cuenta buena parte del lado gráfico” coincide tristemente con mi experiencia usando herramientas de Unity
  DOTS salió, pero da la impresión de que su implementación quedó abandonada, como otras herramientas que Unity adquirió. La operación de la empresa está gravemente mal y, viendo el escándalo público de la política de precios de hace unas semanas, parece más enfocada en cómo sacarle más dinero a los usuarios que en mejorar el motor
  La implementación de ECS en Bevy es realmente buena, y ojalá tenga éxito en este ámbito junto con Godex

  • No entiendo cómo es posible que Unity aparentemente queme hasta mil millones de dólares en ingresos al año y aun así el motor siga sintiéndose como un producto incompleto, a medio cocinar. ¿A dónde va todo ese dinero?
  • Godex al final es como ponerle labial a un cerdo. Puede mejorar un poco el rendimiento, pero ECS no es una optimización mágica que se pueda añadir como si fuera un plugin
    La coherencia de caché en la capa de gameplay no puede arreglar cuellos de botella a nivel de motor
  • Siendo sinceros, hay muchas formas de lanzar un juego con buen rendimiento, y ECS no es ni estrictamente necesario ni necesariamente la forma moderna. Es solo uno de varios patrones arquitectónicos con los que se puede construir un juego, y tiene muchas ventajas y desventajas
    Por ejemplo, Godot no está centrado en ECS, sino en el concepto de “servidores”, subsistemas autónomos del juego que manejan de forma mayormente independiente cada dominio especializado, como renderizado o física, y están acoplados de forma laxa a la lógica general del juego
    La arquitectura ECS viene de la época de PS2/PS3, cuando los CPU eran bastante malos. Con cachés pequeñas, alto costo por fallos de predicción de saltos, memoria lenta, espacios de memoria fragmentados y ausencia de almacenamiento de acceso aleatorio, los desarrolladores tenían que hacer juegos ajustados a patrones de acceso a memoria predecibles, y por eso era común una estructura donde los datos del juego se procesaban en streaming en pequeños bloques
    Ese enfoque sigue siendo en general una buena práctica, pero con CPUs ultrarrápidos, excelente ejecución especulativa, buenos predictores de saltos y decenas de MB de caché, ya no es un requisito estricto. Más aún si consideras que los juegos modernos no han aumentado tanto la escala de lo que ocurre en pantalla comparado con hace 10 o 20 años. Incluso en juegos de acción, sigue siendo raro que el jugador pelee con más de una docena de enemigos al mismo tiempo
    En juegos donde aparecen miles de elementos a la vez en pantalla, normalmente se necesita lógica y procesamiento especializados por separado
  • ¿DOTS no fue hecho dentro de Unity?

• Consejo para quien quiera probar este juego: cambien el escalado de resolución de dinámico a fijo
  En una 3080, el menú principal pasó de estar en un nivel de “10 fps injugables” a que dentro del juego fuera “corre bien sin problemas” en opciones medio-altas

  • También se puede desactivar por completo. En mi 3080 parece generar muchos artefactos de renderizado
  • Esa no es la solución. Hay que desactivar el motion blur y la profundidad de campo. Especialmente la profundidad de campo destruye el rendimiento del menú

• Como referencia, recuerdo que un frame de Crysis, tomando como base una escena de benchmark, tenía algo así como 300 mil vértices o triángulos. Entonces eso equivale a entre 3 y 10 pilas de troncos, dependiendo de en qué dirección me falle la memoria y qué tan mala sea la proporción entre vértices y triángulos de cada modelo

  • Soy el autor: no encontré una forma fácil de contar el total de vértices por frame en RenderDoc, así que no lo medí directamente. Pero en Reddit alguien midió el total de vértices con ReShade, y dijo que en una toma cercana de una ciudad grande podía ir de cientos de millones hasta mil millones de vértices
    Edit: revisé el conteo de vértices y polígonos con RenderDoc. La escena de ejemplo del artículo procesa 121 millones de vértices y más de 40 millones de triángulos
  • Suena correcto. Recuerdo haber visto “1M Triangles” en el HUD de rendimiento y pensar que un millón de triángulos era una locura. Considerando separación de bordes, billboards y demás, probablemente casi no había vértices compartidos

• El estilo de escritura estuvo realmente bueno:
  “Este pass toma unos 8.2 milisegundos, o sea, una cantidad aproximadamente ridícula de tiempo, así que sorprendentemente es muy pesado…”

  • Ojalá más gente mezclara este tipo de pequeño humor incluso en textos algo serios

• “Esta malla de pila de troncos también se usa solo en el pass de renderizado de sombras y tiene más de 100 mil vértices”… pero, ¿por qué?

  • Porque en desarrollo de juegos hay como un millón de cosas de las que preocuparse. Es posible que alguien, o algún software, se haya equivocado con la configuración de LOD. O que el código de LOD dinámico no haya podido hacer culling correctamente de la malla LOD0, o que ese código no se terminara a tiempo, o simplemente que haya otra razón
    Es completamente normal que un juego AAA tenga algunos elementos incompletos y no optimizados. El presupuesto siempre es limitado y el tiempo de desarrollo es corto. Además, es una industria dependiente de éxitos, sin garantías de resultados. Hay algunas formas de aumentar la probabilidad de éxito de un juego, pero suelen estar más del lado de la gestión que del desarrollo, y los ingresos estimados por preventa no suelen ser muy precisos. Así que hay que hacer concesiones para reducir riesgo, recortar costos donde se pueda y bajar la prioridad de los desarrollos más caros. Esas concesiones son mucho más grandes que una sola malla sin optimizar. Una malla no es nada
    Es un dato curioso que esta malla sea LOD0 y que la malla de dientes también sea LOD0. Pero eso por sí solo no derrumba el rendimiento del juego, y tampoco parece muy probable que arreglen eso en lugar de una corrección de rendimiento real. En este hilo hay un poco de obsesión excesiva con este tipo de mallas
    Hay muchos comentarios cargados emocionalmente y no quiero sumarme a eso; solo intento dar más contexto
  • Esto se podría haber resuelto con unos 100 vértices y un normal map inteligente; tal como está, es un nivel de locura
  • El estudio que hizo este juego tiene alrededor de 30 desarrolladores

• ¿La idea sería, en resumen, que el juego usa modelos extremadamente detallados, pero no tiene una forma inteligente de abstraer o hacer culling de cosas que en realidad no van a aparecer como píxeles visibles?
  Y si es así, ¿sería algo fácil de corregir, o es tan central a la estructura que habría que rehacer el diseño desde cero para resolverlo?

  • Solo se puede especular sobre la dificultad de arreglarlo. No soy experto, pero veo el culling y el LOD como pilares importantes del motor. Que no se pueda usar una implementación existente suena realmente mal
    Puede que el “truco” en sí sea bien conocido, pero no creo que implementarlo sea fácil

• DOTS salió de las ideas de Mike Action. Basta con ver su charla de CppCon 2014, “Data-Oriented Design and C++” [1]. Pero, según Twitter, Mike ya dejó Unity
  [1] https://www.youtube.com/watch?v=rX0ItVEVjHc

  • Aunque el post original sí menciona asperezas de DOTS, no vi en el texto nada que realmente permita decir que DOTS sea la causa. Si DOTS fuera el problema, generaría overhead de CPU, pero aquí parece más bien que usaron una cantidad enorme de geometría exageradamente detallada y no implementaron un sistema de LOD
    Si hubieran tenido Nanite de UE5, tal vez lo habrían aguantado de alguna manera, pero una geometría tan excesiva igual habría hecho colapsar todo lo demás
  • ¿Te refieres a ese mismo Mike Action que dijo, basándose en un dataset muy cuestionable salvo por juegos deportivos y similares, que los juegos de 30fps venden mejor que los de 60fps?

• En Proton Experimental pasé 40 minutos tratando de sacar siquiera unos cuantos fps en un mapa vacío a 1080p, pero me rendí y pedí reembolso. Si arreglan el rendimiento terrible, pienso volver a probarlo
  Disfruté muchísimo el 1, así que me da mucha pena no poder jugar esta entrega

  • La solución cabe en un solo tuit -> https://twitter.com/ColossalOrder/status/1716883884724322795
    “Si tienes problemas de rendimiento, recomendamos bajar la resolución de pantalla a 1080p, desactivar la profundidad de campo y los volumétricos, y bajar la iluminación global mientras resolvemos los problemas que afectan el rendimiento”
    Eso fue todo lo que hice para obtener un rendimiento fluido en una AMD Radeon RX 5700 XT
  • En GeForce Now se puede jugar bastante bien. Aun así se traba un poco, pero pude jugar varias horas sin mayores problemas. Hay tirones molestos de vez en cuando, pero son tolerables.