¿Cómo encontrar un equilibrio entre el sistema y TS2012/RW3?

[StrudElRico4427]

La verdad es que es muy interesante, si tengo tiempo esta tarde me los leo.

[Josep]

Muchísimas gracias por la explicación y por todo este estupendo hilo. Ahora ya lo tengo claro y he podido configurar el equipo para el mayor rendimiento y con unos resultados visuales muy razonables.

Saludos:

Javier.-

Ese era el objetivo.

[JORDIHP]

javierfl ha escrit:
Muchísimas gracias por la explicación y por todo este estupendo hilo. Ahora ya lo tengo claro y he podido configurar el equipo para el mayor rendimiento y con unos resultados visuales muy razonables.

Saludos:

Javier.-

Ese era el objetivo.

Objetivo conseguido.
Gracias también por mi parte.

[jorgomu]

Hola a todos,
descubrir las diferencias entre MLAA, mezcla entre MLAA y MSAA, y SSAA ha sido un puntazo y, al menos para mi, la clave de tener una buena calidad de imagen con un desarrollo fluido del simulador y eso que las informaciones del curso de Siggraph son en mi caso mucho barco para poco pirata.
Muchas gracias.
Saludos

[Josep]

Hola de nuevo

A raíz del comentario viewtopic.php?f=44&t=27007&start=30#p290884 me he puesto a testear de nuevo:

Test en la playa de Altoona del escenario 2 de la Ruta Horseshoe curve. En la vista inicial del test aparecen 305 vagones + el escenario (Altoona incluida).

Viasta del escenario del test con 305 vagones y luz de las 18 horas.

Los resultados:

Test1

Test2

Test 3

Comentarios:

Test 1: 18 horas. La influencia de la malla en el escenario es mínima, mientras los diferentes niveles de antialiasing determinan los FPS.
Test 2: Diferencias entre las 12h y las 03 horas: la diferencia de fps es notable. Independientemente de las diferentes configuraciones, lo que "frena" al simulador son las luces nocturnas.
Test 3: Nublado o despejado no afecta. Los fps vienen determinados por la iluminación nocturna.

Conclusiones:

El cálculo con luces de noche es muy diferente al de luces de día. De noche, lo que va a determinar la caída de FPS no es la malla, sino fundamentalmente el nivel de antialiasing.

Los cuellos de botella en cuanto a la malla pueden aparecer si el sistema tiene un equilibrio inadecuado. Es decir, que mientras la CPU pueda ir a buscar los datos en la RAM sin esperar al disco duro, todo va bien. Si debe esperar que los datos pasen del disco duro a la Ram, cuello de botella. Por eso, si tenemos más RAM, superamos un cuello de botella en complejidades de malla en escenario. Si no -y siempre- es necesario tener desfragmentado el disco duro, ya que si además de buscar los datos en él se encuentran no contiguos, apaga y vámonos.

Aunque finalmente lo que nos va a determinar la caída de FPS es la iluminación nocturna. ¿Posibles razones? Seguiremos...

Josep

[444.518]

Y para más 'inri', en el NEC se junta el pan con las ganas de comer: Penn Station y 30th Street son estaciones subterraneas, los escenarios del 'Acela' son con tiempo tormentoso o muy nublado con lluvia y cada coche 'Amfleet' lleva cuatro focos de iluminación productores de una luz roja muy atractiva pero letal para los 'fps'... Manejar todas la luces de Penn Station más las del material rodante debe ser una tortura tanto para la CPU como para la GPU. Lo curioso de estas situaciones de gran carga gráfica es ver como la GPU lleva una carga del 50% y la CPU utiliza practicamente solo un nucleo...

Por otra parte, he trasteado con las configuraciones de la tarjeta gráfica. Por lo que he podido notar, he mejorado el rendimiento del simulador en algunos fps (en ocasiones hasta en 10) agregandole estos parámetros:

nvidiaconfig.jpg (121.17 KiB) Visto 9141 veces

Partiendo de la configuración 'Calidad', he bajado los fotogramas pre-renderizados solo a 1 (lo he probado con ninguno, pero me carga demasiado la GPU) consiguiendo que procesador no se dedique a realizar la tarea de pre-renderizar. La optimización entrelazada, para que se ayuden GPU y CPU suele venir en automático pero se lo he dejado clarito como debe estar. El control de energía lo he puesto al máximo. En los monitores de sistema veo que mientras juego todos los nucleos funcionan y la GPU no se queda 'atontada' en el 50%. Indico que esta configuración no se adapta a todas las máquinas. A mí me funciona pero es muy posible que en máquinas que difieran de la mía no funcione. Y aparte de esto, me he dado cuenta que la opción de bloquear los fps no ayuda en nada: no sube el rendimiento si hay menos de 30 o 60 fps. Lo único que noto es que me atonta el mapa 2D y el editor de rutas y escenarios.

Y una vez más agradecer a Josep la luz que viene aportando a este hilo.

[Bermúdez]

Por otra parte, he trasteado con las configuraciones de la tarjeta gráfica. Por lo que he podido notar, he mejorado el rendimiento del simulador en algunos fps (en ocasiones hasta en 10) agregandole estos parámetros:

nvidiaconfig.jpg

Partiendo de la configuración 'Calidad', he bajado los fotogramas pre-renderizados solo a 1 (lo he probado con ninguno, pero me carga demasiado la GPU) consiguiendo que procesador no se dedique a realizar la tarea de pre-renderizar. La optimización entrelazada, para que se ayuden GPU y CPU suele venir en automático pero se lo he dejado clarito como debe estar. El control de energía lo he puesto al máximo. En los monitores de sistema veo que mientras juego todos los nucleos funcionan y la GPU no se queda 'atontada' en el 50%. Indico que esta configuración no se adapta a todas las máquinas. A mí me funciona pero es muy posible que en máquinas que difieran de la mía no funcione.

Tal vez a mí sí que me funcione (mi pc es muy similar al tuyo), así que voy a probar.

[Josep]

J.,

De entrada no veo ningún cambio testeando (en la zona comentada más arriba):

Sin cambios: 6,49 fps
Cambiando configuración nvidia: 6,45 fps

Josep

[444.518]

En situaciones comprometidas con mucha iluminación esta configuración que utilizo no remedia casi nada, los fps sigue caidos. Sin embargo en situaciones con una iluminación nocturna baja noto mejores resultados.

Seguiremos buscando el toque especial de la receta

[Josep]

Eso, eso, J.: cuantas más ideas y posibilidades, ¡mejor!.

Pero una sugerencia: que se testeen. Es decir, que se comparen resultados medios de fps como mínimo tomados durante 1 minuto, mejor más. En este hilo ya he propuesto qué programa (fraps) y cómo testear. En este y otros temas, me parece que debemos fundamentar nuestras impresiones, y contrastar los resultados.

Lo que hago para poder variar la hora de inicio del escenario (por lo tanto, la aparición de luces nocturnas i diurnas, según nos interese) es clonar el escenario (y así dejamos intactos los originales) y poder así testear el cambio de iluminación. Siempre deberíamos tomar referencias visuales claras -o lo que sea- para inciar y acabar el test en el mismo lugar.

Pienso que si hablamos de luces nocturnas e impacto en RW3 debemos testear rutas creadas para RW3 que implementen en el escenario las luces nocturnas. No creo que nos sirvan en absoluto los otros escenarios.

Mi hipótesis actual se basa en que son los cálculos de antialiasing los que frenan considerablemente el escenario por la noche. He comprobado que si establecemos la calidad como "Más baja" durante el día no muestra las sombras, pero durante la noche sí muestra los impactos de luz, y por tanto, las sombras. Mi hipótesis de trabajo es que el cálculo de sombras de los puntos de luz tiene prefijado el cálculo de antialiasing, el cual busca en el escenario TODOS los elementos 3d que aparecen en su foco. Según esta hipótesis, calcularia pues el antialiasing de traviesas, raíles, elementos de sujeción de las traviesas... No he visto que la malla del material móvil influya de forma decisiva en el tema, de entrada.

Ello me lleva a preguntar para los creadores de escenarios:

¿Se puede decidir que un objeto o determinadas partes de un material no generen sombras? Así podríamos eliminar las traviesas y sus elementos de sujeción de los cálculos, por ejemplo.
En las luces de rw3, ¿podemos determinar si generan sombras y qué tipo de cálculo realizan? Si pudiéramos establecer un cálculo bàsico de sombras en lugar de un afinamiento de antialiasing en las luces...

Josep

[Bermúdez]

Mi hipótesis actual se basa en que son los cálculos de antialiasing los que frenan considerablemente el escenario por la noche.

Pues mi hipótesis es muchísimo más sencilla: el nuevo motor gráfico "TSX" no lo han optimizado como Dios manda.
Tengo otros juegos bastante avanzados gráficamente, y chico, sea la situación que sea, ni bajan los fps ni se ralentiza el juego, y van fluídos como el aceite.
Ya sé que con este post no aporto nada, y lo siento , pero lo tenía que decir.

[444.518]

He efectuado una prueba más en el NEC sobre el escenario más 'burro' en lo que a caída de 'fps' me he encontrado. Se trata de 'Acela Express', el primero de la lista. El tiempo es tormentoso con lluvias fuertes, oscuro, con luces por todas partes. Empiezo con 7 fps en las condiciones gráficas que empleo ('High' en lanzamiento, 'Más alto' en el juego) dentro de la estación. Una vez que salgo de 30th Street doy máximos de 12 o 13. Desespera ver lo lento que va todo. Un tanto cabreado, comienzo a trastear...

Clono el escenario y cambio el tiempo meteorológico a despejado. Igual. Quito las composiciones estáticas de 30th Street (unas 7 u 8 ). Igual. Intento quitar el tráfico... Mucho, mucho tráfico, demasiado para quitarlo antes de navidad... Decido copiar el escenario pero sin tráfico, colocando en el mismo sitio solo al Acela y dandole las mismas condiciones de tiempo y los mismos destinos y horarios. Empiezo el escenario. En 30th Street, con toda su luminaria, nada más empezar doy máximos de 30 fps. Conduzco las 65 millas hasta Metropark 1 con una media de 26 fps medidas con 'FRAPS'...

Estoy empezando a pensar que el problema que tiene el RW3 no es gráfico, si no estructural. Cuando un escenario está cargado de tráfico, el simulador se preocupa más en calcular las físicas de todos los objetos 'sobre-vía' que en representar la simulación gráfica. La prueba más evidente es que quitando el TSX y poniendo todo el aspecto gráfico al mínimo casi no se mejoran resultados en el mismo escenario, pero eliminando objetos sobre vía el simulador cambía de comportamiento radicalmente. Y por lo que veo, el RW3 usa solo un núcleo para hacer estos cálculos...

La única solución que veo es que en RSC trabajen para mejorar la implementación multi-núcleo para el motor físico del juego.

[Repo]

La única solución que veo es que en RSC trabajen para mejorar la implementación multi-núcleo para el motor físico del juego.

Se está trabajando precisamente en mejorar la funcionalidad del multi-core, próximamente entrará a pruebas una nueva versión que incluye estas mejoras.

Saludos.

[Bermúdez]

He efectuado una prueba más en el NEC sobre el escenario más 'burro' en lo que a caída de 'fps' me he encontrado. Se trata de 'Acela Express', el primero de la lista. El tiempo es tormentoso con lluvias fuertes, oscuro, con luces por todas partes. Empiezo con 7 fps en las condiciones gráficas que empleo ('High' en lanzamiento, 'Más alto' en el juego) dentro de la estación. Una vez que salgo de 30th Street doy máximos de 12 o 13. Desespera ver lo lento que va todo. Un tanto cabreado, comienzo a trastear...

Clono el escenario y cambio el tiempo meteorológico a despejado. Igual. Quito las composiciones estáticas de 30th Street (unas 7 u 8 ). Igual. Intento quitar el tráfico... Mucho, mucho tráfico, demasiado para quitarlo antes de navidad... Decido copiar el escenario pero sin tráfico, colocando en el mismo sitio solo al Acela y dandole las mismas condiciones de tiempo y los mismos destinos y horarios. Empiezo el escenario. En 30th Street, con toda su luminaria, nada más empezar doy máximos de 30 fps. Conduzco las 65 millas hasta Metropark 1 con una media de 26 fps medidas con 'FRAPS'...

Estoy empezando a pensar que el problema que tiene el RW3 no es gráfico, si no estructural. Cuando un escenario está cargado de tráfico, el simulador se preocupa más en calcular las físicas de todos los objetos 'sobre-vía' que en representar la simulación gráfica. La prueba más evidente es que quitando el TSX y poniendo todo el aspecto gráfico al mínimo casi no se mejoran resultados en el mismo escenario, pero eliminando objetos sobre vía el simulador cambía de comportamiento radicalmente. Y por lo que veo, el RW3 usa solo un núcleo para hacer estos cálculos...

La única solución que veo es que en RSC trabajen para mejorar la implementación multi-núcleo para el motor físico del juego.

Yo experimento los mismos problemas en este escenario también.

La única solución que veo es que en RSC trabajen para mejorar la implementación multi-núcleo para el motor físico del juego.

Se está trabajando precisamente en mejorar la funcionalidad del multi-core, próximamente entrará a pruebas una nueva versión que incluye estas mejoras.

Saludos.

Excelente noticia.
Esperemos que esas mejoras sean realmente tangibles.

[444.518]

Se está trabajando precisamente en mejorar la funcionalidad del multi-core, próximamente entrará a pruebas una nueva versión que incluye estas mejoras.

Saludos.

Creo que a ninguno nos hubiera importado mucho que la actualización de RW2 a RW3 se hubiera realizado con más tiempo, pero que se hubiera hecho de forma completa, no solo actuando solamente sobre motor gráfico, si no también sobre el motor del juego. Ahora tenemos un simulador muy bonito pero que hereda un motor de juego sin optimizar para la nueva versión, y deja inservible al simulador en determinadas ocasiones.

Tirón de orejas para RSC