Moderador: Moderadores
blas_dani escribió: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.
Repo escribió: 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.
2TE116 escribió:el problema son las luces???
blas_dani escribió: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.
Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 65 invitados