North East Corridor

[444.518]

En mi caso no se trata de carencia de RAM, ya que funciono con 8GB y casi nunca llego a llenar la mitad. Gracias al monitor doble puedo comprobar en un monitor la RAM, los nucleos del procesador, los procesos y la gráfica mientras uso pantalla completa en otro monitor. El NEC suele ocuparme bastante memoria, 1.5GB a 1.8GB, aunque hay rutas que ocupan más, como la WMLCN que a veces llega a llenar 2.3GB. En los sistemas que tengan menos de 4GB de RAM debe ser bastante notable el movimiento de datos entre la RAM y el archivo de paginación. Recuerdo que con RW2 y 1GB de RAM, Oxford-Paddington llegaba a tardarme en cargar casi 5 minutos...

[Josep]

Un comentario: testeando la ruta (mañana os cuento, pero adelanto que Acela express tiene algo de estructura, como bien comenta J., que la frena, y que la hace prácticamente insensible a TODOS los ajustes gràficos) me he dado cuenta que en determinadas circunstancias (saliendo y entrando de un escenario a otro, por ejemplo, sin salir de Rail simulator) al entrar en el escenario del "Acela express" se clava a 5 fps, siendo absolutamente injugable. Si salgo totalmente del simulador y lo vuelvo a arrancar, entrenado de nuevo al escenario, vuelvo a mis 10 fps inicales del escenario en mi configuración gráfica.

Ojo con el tema. Quizá sea una pista más del equilibrio inestable de ésta ruta con el simulador y el sistema.

Josep

[Josep]

Hola,

Está claro que NEC tiene "algo" que frena los FPS. La malla (como dice el compañero 444.518 en este post) influye, es cierto. Pero NEC se comporta de forma diferente a "Horseshoe Curve" y al resto de rutas, especialmente en el escenario Acela Express.

Lo he estado analizabdo casi al detalle. Inicialmente me cuesta comprender el porqué el escenario AE (Acela Express) no "se immuta" ante cambios en la configuración del simulador. Segú mis comentarios en el hilo ¿Cómo encontrar un equilibrio entre el sistema y TS2012/RW3? debemos empezar por ajustar antialiasing, resolución y nivel de detalle para mejorar los FPS. Para mí, el mínimo mínimo son 10-15 FPS, en donde coloco la línea entre jugable o no.

Testeamos. Proceso: programa Fraps, iniciamos el escenari "Acela express" y al segundo 25 pulsamos F11 para inciar Fraps con solamente la opción "FPS" activa. A 28 mph, pulsamos la tecla "k" para activar el control de velocidad automático. Pasada la señal de 60 mph, potencia al máximo hasta llegar a la indicaciñón de 90 mph, y pulsamos de nuevo F11 para parar test. (Gracias, 444.518, por la por la propuesta). Utilizo en estas pruebas el escenario "Acela express" tal como viene en la ruta.

Vamos a ello, a por el antialiasing:

Va a ser que no. Pues probemos el Detalle gráfico:

No se entera. (Ojo, que para mí el mínimo seria el nivel Medio). Nada. A bajar resolución:

Ni se entera. Esto suena ya a raro. La malla, como se dice. Sí, ¡¡pero el simulador no hace ni caso del resto de parámetros de ajuste del nivel gràfico!! Vamos a testear estableciendo el mínimo elementos del detalle gráfico:

Significativo el que ni se immuta. Especialmente significativo como muy atípico el hecho que casi no se aprecia cambio al establecer la distancia de visión al mínimo. Esto significa, sin lugar a dudas, que existe algún elemento en la ruta que “frena” los cálculos, hace como una áncora en el sistema.

¿Qué podria ser? ¿Que la unidad Acela tuviera una programación no adecuada de los “gauges” o pantallas? ¿Qué el sistema implementado de avisos en cabina de velocidades en la ruta influyera negativamente?

Esto seria visible si cambiamos la unidad Acela por otra:

Pues tampoco. Me resisto a pensar que únicamente puede ser la malla, ya que el “no immutarse” es absolutamente atípico. Si hay mucha malla, precisamente cambiando resoluciones, antialias y detalles gráficos DEBEN mejorar los FPS de forma más significativa que en los tests realizados.

Esto ya es un reto en toda regla. Repasando el hilo, aparece el comentario de David (enanin) en el que menciona el tema de las luces en el escenario. Buena pista, sí señor: se propone eliminar (¡¡hacer copia antes!!) la carpeta Lights que se encuentra en …\Steam\steamapps\common\railworks\Assets\RSC\NorthEastCorridor.

Lo hago, y nuevo testeo:

¡Otro mundo existe en este escenario!

Seguirá.

Josep

[2TE116]

el problema son las luces???

[blas_dani]

Hola:

Si os sirve de referencia, creo que la explicación está en el Acela. (el tren).

Si alguien de vosotros tiene el Pendolino observarà que requiere más recursos que otro material. El motivo puede ser desde la malla, hasta que exista un gran número de scripts implicados en la simulación de su funcionamiento que se ejecutan de forma concurrente en tractoras y vagones (desde la señalización en cabina, pasando por chispas en el pantógrafo, pendulación, etc etc... la ejecución de scripts no deberia influir en el motor gráfico, pero si en la carga de la CPU, que a su vez depende de otros factores. También podria ser que alguno de los script tuviera alguna función con un bucle descontrolado... por un error en el diseño. En escenarios con poca carga esas cosas no se aprecian; si vamos justos entonces, si.

Otra cosa no se me ocurre.

PD: estoy intrigado por como haceis esos gráficos.

Saludos.

[444.518]

Intrigado con el comportamiento de las luces en este escenario, he decidido mirar los 'blueprints' de las luces se utilizan en él, con el proposito de averiguar si entre ellas se encuentran focos o puntos de luz con la característica 'catshadows' activada, produciendo sombras que requieran cálculos muy potentes. Solo en tres puntos de luz he encontrado activados 'catshadows': los archivos 'Loco_Headlight' en los directorios 'Lights' del NEC, el AEM-7 y el Acela. El resto de luces son focos sin sombras. Decidido a probar si las sombras de estas luces son las resposables, he tocado esta propiedad desactivandola, pero no he conseguido grandes cambios en la jugabilidad del escenario. Por lo visto es todo o nada, correr el escenario con luces aunque no produzcan sombra no parece ser gran adelanto.

PD: Los gráficos los hago con los datos ofrecidos por 'Fraps' y abriendolos con 'OpenOffice Calc'. Con Excel se hacen de manera parecida.

[Repo]

Hola:

Si os sirve de referencia, creo que la explicación está en el Acela. (el tren).

Si alguien de vosotros tiene el Pendolino observarà que requiere más recursos que otro material. El motivo puede ser desde la malla, hasta que exista un gran número de scripts implicados en la simulación de su funcionamiento que se ejecutan de forma concurrente en tractoras y vagones (desde la señalización en cabina, pasando por chispas en el pantógrafo, pendulación, etc etc... la ejecución de scripts no deberia influir en el motor gráfico, pero si en la carga de la CPU, que a su vez depende de otros factores. También podria ser que alguno de los script tuviera alguna función con un bucle descontrolado... por un error en el diseño. En escenarios con poca carga esas cosas no se aprecian; si vamos justos entonces, si.

Otra cosa no se me ocurre.

PD: estoy intrigado por como haceis esos gráficos.

Saludos.

Hola, los scripts del material rodante no tienen ni el más mínimo efecto de carga sobre el procesador aun cuando sea un script grandote calculando valores con bastantes decimales y a intervalos de tiempo muy cortos. Si uno pudiera comparar la carga de este tipo de script en LUA con la carga que produce el core del simulador en C++, se daría cuenta que las funciones de dicho script tienen un efecto realmente despreciable en el rendimiento general.

Yo creo que el principal problema de la ruta NEC es que fue hecha para RW2 y luego adaptada un poco a la fuerza a TS2012, no podría darles detalles porque yo no participé en nada para esta ruta, excepto en contribuir con el Acela Express. La diferencia con Horseshoe Curve es que ésta se diseñó para TS2012 desde un principio y se tuvo de antemano un especial cuidado en el rendimiento.

Saludos.



Saludos.

[Josep]

Hola, los scripts del material rodante no tienen ni el más mínimo efecto de carga sobre el procesador aun cuando sea un script grandote calculando valores con bastantes decimales y a intervalos de tiempo muy cortos. Si uno pudiera comparar la carga de este tipo de script en LUA con la carga que produce el core del simulador en C++, se daría cuenta que las funciones de dicho script tienen un efecto realmente despreciable en el rendimiento general.

Yo creo que el principal problema de la ruta NEC es que fue hecha para RW2 y luego adaptada un poco a la fuerza a TS2012, no podría darles detalles porque yo no participé en nada para esta ruta, excepto en contribuir con el Acela Express. La diferencia con Horseshoe Curve es que ésta se diseñó para TS2012 desde un principio y se tuvo de antemano un especial cuidado en el rendimiento.

Saludos.

Saludos.

Ahí le estás dando a la diana. La adecuación de NEC a RW3 (añadendo luces, sobre todo) genera una problemática difícil de solucionar sin rediseñar el escenario, denso ya de por sí, problemática que en Horseshoe Curve no aparece (por lo menos, ajustando parámetros del juego se pueden mejorar los FPS). Estoy terminando de testear si el día o la noche influye (en Horseshoe sí), pero parece que va a ser que no.

En todo caso, por ahora solamente encontramos un nuevo equilibrio eliminando la carpeta Lights del escenario NEC. Ninguna otra opción parece ser eficaz.

Urge que se desarrolle un avance en el juego que implemente el uso de Multi-core de forma adecuada, no tal como funciona ahora. Seguramente el problema se resolvería. En todo caso, pienso que Railworks se la va a jugar en el nuevo escenario anunciado creado de entrada para RW3: si no consiguen implementar de forma adecuada un equilibrio con la iluminación nocturna, deberán desarrollar una mejora del motor gráfico.


Saludos!

Josep

[Josep]

el problema son las luces???

Respuesta: SÍ. O al menos, buena parte del problema.

He estado trabajando el tema de las luces. Los ficheros de luces correspondientes a la ruta NEC, a Acela y a AEM7 son los siguientes (en amarillo, el contenido de la subcarpeta "Textures"):

Ficheros de luces de la ruta NEC

FitxersNECLights.jpg (138.65 KiB) Visto 12285 veces

Ficheros de luces de AEM7

Ficheros de luces de ACELA

FitxersNECAcela.jpg (91.35 KiB) Visto 12285 veces

De entrada, ¿qué sorprende?

1) La existencia de ficheros con el mismo nombre en las carpetas de luces de la ruta NEC, de ACELA y del AEM7. En concreto, los ficheros Loco_Headlight.bin, Loco_Headlight_glow.bin y Loco_Taillight.bin.

2) La existencia de ficheros “especiales” que entendería como de la ruta y que se encuentran en la carpeta de luces de la ruta NEC y que aparecen duplicados en la carpeta de luces de AEM7, como Clutter_Lamp_Glow.bin y especialmente el fichero Hudson_Tunnel_Lamp.bin. ¿Qué hace un fichero de luces de un túnel en la carpeta de luces de una locomotora?

3) La existencia de aparentemente los mismos ficheros en las carpetas Textures.

4) Comparando con los ficheros de luces de ACELA, en AEM7 no aparece el fichero point_light.bin pero sí su textura en la subcarpeta Textures.

5) Si se eliminan de la carpeta Lights de la ruta NEC los ficheros point_light.GeoPcDx y spot_light.GeoPcDx (por cierto, que ya aparecen en la subcarpeta Textures) DESAPARECE LA ESTACIÓN INICIAL del escenario Acela Express. (En una de las pruebas, eliminando los mismos ficheros de la carpeta Lights del ACELA, me desapareció ¡¡¡la malla del AEM7!!!).

No veo ninguna lógica lógica en estos comportamientos, y me intuyo algo: me parece entrever duplicidades de ficheros, y consiguientemente, de cálculos… La clave puede estar en los ficheros Loco_Headlight.bin, Loco_Headlight_glow.bin y Loco_Taillight.bin.

Me dedico a borrar, cambiar nombres, etc… obteniendo el siguiente resultado, sorprendente para mí.

Conclusión 1: Si se elimina (ojo, ¡¡¡hacer copia antes!!!) la carpeta Lights del AEM7, TODO SIGUE IGUAL: sus luces funcionan, vamos matados de FPS…

Conclusión 2: Si se mantiene la carpeta Lights del AEM7 y se eliminan los ficheros Loco_Headlight.bin, Loco_Headlight_glow.bin y Loco_Taillight.bin de la carpeta Lights de NEC:

- el resultado en FPS es el mismo que si eliminamos toda la carpeta Lights de NEC.
- mantenemos las luces del escenario, menos las de las unidades AEM7.

Los tests de FPS:

Tests con niveles gráficos medios

Tests con nivel gráfico más alto

Ahora estudiando el comportamiento y la influencia de los 3 ficheros... "loco*.bin"

Josep

[blas_dani]

Hola:

Respecto tus observaciones, no creo que vayan por ahí los tiros.

1) y 3) Los archivos de texturas pueden estar repetidos ya que acela se vende aparte. Son texturas de un punto de luz que los sres de RSC han aprovechado para varias cosas y que probablemente los encontremos en otras rutas/material.

2) Los .bin son los blueprints que definen las coordenadas de las luces en cada màquina, etc; en acela y aem7 aunque tengan el mismo tamaño, seguro que son distintos ya que las coordenadas de las luces en uno y otro material son diferentes.
Por lo que comentas en las conclusiones, parece que los sres de RSC tienen las luces del AEM7 (que viene con la NEC) definidas en la carpeta de la ruta, no en la del material. Eso es un error en las path de los archivos, pero seguro que no se cargan más de una vez.

4) Probablemente sobrará esa textura (no puedo ver el contenido de los .bin ya que no tengo ese material/ruta).

5) Eliminando los archivos de geometria de luces provocas que el objeto madre que los necesita desaparezca, ya que no lo puede representar. Sólo que desde el blueprint de la estación principal se haga una llamada a los blueprints donde estan definidos esos assets provoca que no se represente ese objeto. Es normal.
Lo del AEM7 con el ACELA no lo entiendo... no será eliminando los ficheros de la carpeta lights de la NEC?


Como dice Repo, lo más probable es que la caida de rendimiento sea debida a algunos objetos que interacionan mal con las nuevas funcionalidades del RW3 (luces y sombras) por tener defectos en la malla; tenemos el ejemplo de las vias 3D de Camber, que en una ruta tan sencilla como la Testrack 1668 hacen que sea injugable.

Saludos.

[Josep]

bas_dani

Gracias por las aclaraciones. Pero las pruebas son las pruebas. Por ahora estoy intentando demostrar que en mi sistema -y probablemente en el de todos- los ficheros Loco_Headlight.bin, Loco_Headlight_glow.bin y Loco_Taillight.bin que se encuentran en la carpeta Lights de la ruta NEC (...\Steam\steamapps\common\railworks\Assets\RSC\NorthEastCorridor\Lights) influyen DECISIVAMENTE en los FPS del escenario Acela Express, esté previsto o no por los creadores de la ruta. Lástima que no puedas comprobarlo tú mismo, ya que en 3D de lo previsto al resultado...

Por otro lado, ya hace tiempo que lancé la hipótesis -cada vez más comprobada- que las vias y traviesas, junto con las luces y el antialiassing generan en RW3 cuellos de botella importantes que afectan a los FPS.

Seguimos con ello.

Josep

[Josep]

And the winner is... Loco_Taillight.bin

Influencia de los ficheros loco*.bin en los FPS

Por lo tanto, una opción -la única, por ahora- de poder ajustar los parámetros gràficos del escenario Acela Express de la ruta NEC es (ojo, hacer copia antes) eliminar el fichero Loco_Taillight.bin de la carpeta ...\Steam\steamapps\common\railworks\Assets\RSC\NorthEastCorridor\Lights. Aunque se elimine, en principio se mantiene toda la iluminación del escenario.

¿Porqué este fichero influye en la jugabilidad del escenario y la ruta? ¿Cuál es el efecto visual de eliminarlo de la ruta?

Josep

[blas_dani]

Hola:

Mirando la HorseShoe que si tengo, los archivos de definición de luces (los bin) son unos sencillos blueprints que definen las características y color de la luz y el asset (la malla y la textura) del punto de luz.

El punto de luz se define por un archivo de malla (el GEOPCDX) y una o más texturas (archivos TGPCDX), según el shader usado (hay shaders que tienen varios slots para varias texturas).

La malla imagino que será un simple polígono, como siempre hemos hecho, con una textura pequeñaja que define el 'halo' con su correspondiente canal alpha.

Si tu suposición es cierta, ya sea en la malla o en la textura hay un contubernio que hace bajar el rendimiento en fps para esas luces concretas. Otra posibilidad seria que la definición de las características de la luz (radio, etc) provoque algún efecto no deseado por error..

Por tanto, si editas los bin y usas otra luz (otro archivo de malla con sus texturas) veriamos si estás en lo cierto.


Sinceramente, dudo que algo tan simple provoque por si mismo esa pérdida de rendimiento.

Saludos.

[Repo]

Hola:

Mirando la HorseShoe que si tengo, los archivos de definición de luces (los bin) son unos sencillos blueprints que definen las características y color de la luz y el asset (la malla y la textura) del punto de luz.

El punto de luz se define por un archivo de malla (el GEOPCDX) y una o más texturas (archivos TGPCDX), según el shader usado (hay shaders que tienen varios slots para varias texturas).

La malla imagino que será un simple polígono, como siempre hemos hecho, con una textura pequeñaja que define el 'halo' con su correspondiente canal alpha.

Si tu suposición es cierta, ya sea en la malla o en la textura hay un contubernio que hace bajar el rendimiento en fps para esas luces concretas. Otra posibilidad seria que la definición de las características de la luz (radio, etc) provoque algún efecto no deseado por error..

Por tanto, si editas los bin y usas otra luz (otro archivo de malla con sus texturas) veriamos si estás en lo cierto.


Sinceramente, dudo que algo tan simple provoque por si mismo esa pérdida de rendimiento.

Saludos.

Los objetos o assets que acompañan a los archivos *.bin de luces no son ni más ni menos que simples geometrías tendientes a ayudarlo a uno a colocar las luces correctamente en los editores, esos objetos jamás se ven ni representarán en el juego y por lo tanto no tienen ninguna injerencia en el rendimiento. Cuando uno pasa del modo simulación al modo World Editor puede ver como en las locomotoras que poseen luces aparecerán unos objetos parecidos a linternas gigantes, bueno pues esos son precisamente los objetos a los que me refería. En rigor y por lo general, los puntos de luz no contienen ninguna geometría ni textura, simplemente son blueprints (*.bin) que indican al core del simulador el tipo, intensidad y color de la luz.

Saludos.

[blas_dani]

Gracias Repo... me has aclarado una duda.

La verdad es que pensaba que el halo proyectado tenia que ver de alguna manera con ese objeto.

Saludos.