RS:Consideraciones generales de creación en RS
De TrenSimpedia
Este documento es una explicación del contenido de parte de la documentación oficial de Rail Simulator, en particular de los documentos de las Developer Tools:
- 4.03 General Guidelines and Considerations
- 4.04 Asset Authoring Guidelines
- 4.11 Lighting and Shadows
|
Este artículo o sección se encuentra en fase de desarrollo por parte de un contribuidor. Es posible que la información suministrada aquí no sea completa. Ampliándolo ayudarás a mejorar la TrenSimpedia, pero recuerda que alguien posiblemente ya tiene en mente completarlo.
|
Contenido |
Orientación y origen
Salvo indicación en contra, el origen o punto de giro de una creación debe colocarse en el centro de la base de los objetos.
Una manera fácil de hacerlo es centrar de punto de giro en el objeto, mediante la función habitual del editor, y, a continuación, mover el punto de giro vertical hacia abajo hasta el nivel del suelo (el centro de la base).
El centrado del origen es importante para la correcta actuación de la esfera de visión de los objetos en la simulación.
Así mismo, facilita la correcta colocación y ubicación de los objetos sobre el terreno.
Escala
Todos los objetos deben construirse en metros, en el editor 3D respectivo, para un escalado correcto en la simulación.
Guía básica de construcción
 |  |
Por regla general, los pequeños detalles de una creación no deben estar fusionados en el objeto que da volumen a la forma principal. Simplemente, el modelo debe construirse añadiendo elementos al objeto principal como subelementos.
Esto tiene una serie de ventajas:
- Tiende a mantener el número de polígonos bajo para cada elemento individual.
- Facilita posteriormente la creación de LODs, pues es sencillo asignar a los detalles una distancia de visión inferior a la del modelo principal.
Texturas
Como norma general, las texturas de un objeto deben residir en una carpeta por debajo de la que contiene el objeto llamada "texturas". Las texturas de los objetos se pueden compartir a través de objetos de una misma clase. Por ejemplo, un edificio puede compartir texturas de otro edificio y un vehículo de carretera puede compartirlas con otro vehículo de carretera, etc.
Es importante que tratemos de mantener una resolución de textura "Texel" similar entre polígonos vecinos. Si se trabaja con un Texel muy diferente en polígonos cercanos, es posible que haya una muy baja resolución adyacente a una textura de mayor resolución y, debido a los métodos de filtrado empleados, una se verá muy contrastada y la otra muy borrosa. Este es un efecto visual molesto e indeseable.
Se debe procurar mantener el número total de texturas utilizadas en un modelo lo más bajo posible. Es preferible unir todas las texturas de un modelo en una única hoja de texturas de mayores dimensiones.
Grupos de Texturas
En la medida que queramos aprovechar la dinámica sobre la hora del día y las estaciones anuales en el juego, vamos a tener la necesidad de proporcionar grupos de diferentes texturas a algunas creaciones, principalmente medioambientales. Son las denominadas Texturas estacionales.
Para ello nos vamos a poder apoyar en hasta 4 grupos de texturas por objeto:
- Primavera - La vegetación puede tener un follaje verde y flores
- Verano - Representa las condiciones de iluminación normales (por defecto)
- Otoño - La vegetación puede tener un follaje amarillento y marchito
- Invierno - Predominantemente, nieve en la textura
La asignación de una textura a uno de estos cuatro grupos se determinará a través de un sufijo al nombre convencional de la textura.
Para el grupo normal (por defecto, o verano), las texturas de un objeto tendrán el nombre sin sufijo.
El resto de texturas necesarias para las otras variantes estacionales tendrán los siguientes sufijos.
- _sp - para primavera
- _au - para otoño
- _wi - para invierno
A título de ejemplo, para una textura denominada "casa_1" que deba tener únicamente texturas adicionales de invierno, ésta última se denominaría "casa_1_wi".
El grupo de texturas se determina al inicio de un escenario, según las condiciones del mismo. Durante una misma sesión o escenario en el juego no se produce ningún cambio de grupos de texturas para los objetos.
En el editor, el objeto deberá ser texturado con el grupo por defecto (sin sufijo) y será en el proceso de exportación cuando se procederá a añadir (de forma automática) el resto de texturas, si estas existen.
|
No es necesario que todo el juego de texturas completo esté presente en todos los grupos (sufijos). El exportador añadirá tan sólo aquellos que se encuentren en el mismo directorio de texturas del grupo normal (sin sufijo). |
Este es un sistema flexible que permite a un usuario crear tan sólo aquellas texturas estacionales que considere necesarias para sustituir las texturas base en cada caso.
Típicos ejemplos de juegos de texturas son:
| Primavera | Base (Verano) | Otoño | Invierno | |
|---|---|---|---|---|
| Vegetación | Hojas "jóvenes"" y flores | Follaje exuberante | Hojas amarillentas y secas | Ramas cubiertas de nieve |
| Edificios | ninguna | Textura normal | ninguna | Edificio cubierto de nieve en tejados y balcones |
| Vehículos | ninguna | Textura normal | ninguna | ninguna |
| Terreno | ninguna | Terreno normal | ninguna | Terreno nevado |
Transparencias y canal Alpha
Si es necesario el uso de transparencias en una textura:
- Debe usarse un shader SIN-alpha (por ejemplo, TexDiff, TrainLightMapWithDiffuse.fx, etc.).
- La textura debe guardarse como una imagen full-32 bits (sin paleta de colores) con canal alpha.
- En 3DS debe marcarse el flag TRANS del material.
- Para obtener los mejores resultados, en el canal alpha sólo debe usarse los colores negro y blanco (no el habitual degradado de escala de grises de 256 colores). Negro para las zonas de transparencia total y blanco para las zonas opacas.
No hay una verdadera ordenación alpha en el motor de juego. Por lo tanto no es aconsejable el uso de shaders con alpha, pues en caso de usarse, los polígonos con alpha mostrarán incorrectamente los objetos situados detrás suyo en el motor de juego.
|
NOTA: Las texturas en 256 colores con canal alpha no están soportadas en el juego y no se mostrarán correctamente. |
Compresión
A todas las texturas les es aplicada una compresión DX en el proceso de exportación de un objeto de forma predeterminada. En la mayoría de los casos, esto ahorra espacio en la textura, y la visible disminución de calidad que implica no es perceptible.
Sin embargo en ciertos tipos de textura (por ejemplo, texturas con gradientes muy sutiles) pueden aparecer efectos indeseados, "jaggy" y "bandas", una vez comprimidas.
|
NOTA: Si el archivo tiene el sufijo _nm, la textura no será comprimida. |
Esto es necesario habitualmente en aquellas texturas que incluyan un "mapa de normales"
Preiluminación
Podemos pre-iluminar nuestros objetos con una iluminación global "falseada" mediante el uso de shaders en el material que implementan un segundo paso de iluminación mediante una textura específica.
La iluminación de esta textura no debe tener una dirección predominante muy marcada, ya que recordemos que el objeto también recibirá la iluminación dinámica del juego. La pre-iluminación de los edificios permitirá que estén difuminadas las sombras bajo salientes y en torno a los detalles. Esto proporcionará una apariencia más real y contribuirá a acentuar el detalle de los objetos sin incrementar sus polígonos.
Iluminación Nocturna
El artículo Iluminación Nocturna en RS explica la implementación de esta característica en los objetos RS más ampliamente.
Shaders
En el modelado 3D el shader es un algoritmo que especifica como una superficie responde ante la luz y cuales son sus propiedades de renderizado.
Para algunos shaders, es necesario realizar múltiples pasadas para conseguir los efectos de textura. Un ejemplo de ello sería un shader con mapas de reflejos, donde la reflexión del mapa se aplica en una segunda pasada en tiempo de ejecución.
Algunas de las descripciones que figuran en los shaders hacen referencia a una "textura dummy" en una o varios de los slots (ranuras) de texturas del material. Estas ranuras son para una "falsa" textura que permite que el simulador pueda efectuar uno de estos efectos con múltiples pasadas en tiempo de ejecución. Por lo tanto, el contenido de estas "texturas dummy" es irrelevante (ya que se sustituye el mismo en tiempo de ejecución por otra textura generada por el simulador).
No obstante, a fin de garantizar que el shader mantenga la coherencia, se recomienda crear una misma textura pequeña (denominada por ejemplo "Dummy.ace") y usarla en todos los slots que la necesiten.
Hay dos tipos de shader en Rail Simulator: Shaders no-FX y Shaders FX
Shaders no-FX
Estos shaders son menos complejos que los FX y requieren menos pasadas de texturas. Por tanto cargan menos el motor del juego, pero presentan resultados más básicos que los shaders FX.
| Shader | Descripción | Ejemplos de uso |
|---|---|---|
| Tex | Este shader no está afectado por la luz (falta de luz) nunca se oscure | Interior de coches de viajeros, y ventanas de edificios por la noche (opacas). |
| TexDiff | Este shader está afectado por la luz ambiente (general) y por la luz difusa (direccional dependiendo de la posición del sol o la luna). | Objetos escénicos en general que no requieren mapas de sombras. |
| BlendATexDiff | Este shader actual igual que TexDiff, pero además usa el canal alpha para generar transparencias degradadas mediante blending alpha. | Ventanas de los trenes. |
| AddATex | Este shader usa la textura (no el canal alpha) para adicionar luz sobre otros objetos mediante additive alpha. | Proyecciones de focos de luz en el suelo o paredes. |
| SubtractATexDiff | Este shader usa la textura (no el canal alpha) para sustraer luz sobre otros objetos mediante subtractive alpha. | Sombra bajo los vehículos. |
Los shaders no-FX renderizan los polígonos por una sola cara por defecto.
Shaders FX
Estos shaders son más complejos que los no-FX y pueden requerir más pasadas de texturas. Por tanto pueden ser más costosos para el motor del juego, pero presentan resultados con más profundidad y, en general, superficies más reales e interesantes que los shaders no-FX.
| Shader | Descripción | Ejemplos de uso |
|---|---|---|
| StencilShadow.fx | Este shader se usa específicamente para texturar el patrón de sombras del modelo. Para que este shader actúe correctamente es importante tener presente las consideraciones que se exponen en el artículo Sombras dinámicas en RS. | Elementos patrones de sombras de los objetos. |
| TrainFlora.fx | Este shader está afectado únicamente por la luz ambiente (general), no por la luz difusa (direccional). | Grupos de hojas y vegetación. |
| TrainViewFacingFlora.fx | Este shader está afectado únicamente por la luz ambiente (general), no por la luz difusa (direccional) y además muestra siempre la textura orientada hacia la cámara. | Grupos de hojas y vegetación. |
| TrainUprightViewFacingFlora.fx | Este shader está afectado únicamente por la luz ambiente (general), no por la luz difusa (direccional) y además muestra siempre la textura orientada hacia la cámara. | Grupos de hojas y vegetación. |
| LoftTexDiff.fx | Este shader se usa para texturar objetos procedurales (lofts) generados por el juego. | Un muro de piedra, vías, carreteras... |
| LoftTexDiffTrans.fx | Este shader se usa para texturar objetos procedurales (lofts) generados por el juego. Además soporta transparencias. | Un vallado de alambre, una hilera de vegetación de fondo... |
| WaterCubeMap.fx | Este shader se usa para generar superficies de agua. | Rios, lagos... |
| TrainBasicObjectDiffuse.fx | Versión FX del shader básico TexDiff | Objetos en general (que NO requieren mapas de sombras). Se recomienta su uso generalizado cuando no es necesaria ninguna característica especial. |
| TrainEnv.fx | Este shader tiene una segunda pasada de textura para un mapa de reflexión. | Ventanas de cristal que deben reflejar la luz del sol en edificios (opacas). |
| TrainLightMapWithDiffuse.fx | Este shader implementa una segunda pasada para un mapa de sombras, que permite al objeto tener una preiluminación que ayuda a dar mayor profundidad a la iluminación del objeto. | Edificios y estaciones. |
| TrainBumpSpecEnvMask.fx | Permite asignar al objeto mapa de normales (bump), especulares y de reflexión. | Metales brillantes en relieve, laterales de locomotoras (con apariencia irregular) |
| TrainSpecEnvMask.fx | Permite asignar al objeto mapa especular y de reflexión. | Metales brillantes lisos, laterales de locomotoras y coches modernos (con apariencia regular) |
| SkinDiffuse.fx | Shader de piel especialmente desarrollado para los personajes en el juego. | Piel de personas o animales. |
| TrainSkyDome.fx | Shader desarrollado concretamente para la creación de cielos dinámicos en el juego. | Cielo y nubes. |
Los shaders FX renderizan los polígonos por las dos caras por defecto.
Jerarquía
Nomenclatura y LODs
Todos los objetos deben seguir unas convenciones de nomenclatura. Cada nombre empezará con una cifra que representa el nivel de LOD (distancia de visión), seguida por 4 dígitos que determinan la distancia la que será visible dicho nivel de LOD, separados mediante el carácter subrayado. Después de esto, lógicamente, el nombre de objeto elegido limitado a un máximo de 31 caracteres.
Todos los nombres deben estar totalmente en minúsculas.
n_dddd_name
- n = LOD siendo 1 el LOD más cercano existente
- dddd = cuatro dígitos para la distancia de visión del LOD (rellenado con ceros por la izquierda si es necesario)
- name = nombre lógico del objeto
Caso especial - 0000 como distancia de visión (dddd) hará que el LOD siempre se renderice si está en el campo de visión.
Un ejemplo de nombres para un elemento denominado casa01 podría ser:
1_0050_casa01 2_0100_casa01 3_1000_casa01
El primer LOD (el de mayor detalle) para casa01 será visible desde 0m a 50m, el segundo LOD será visible desde 50 metros a 100 metros y el último LOD será visible desde 100m hasta 1000m. Este objeto no será visible más allá de 1000 metros.
Otro ejemplo para un objeto denominado tunnel04 podría ser:
1_0100_tunnel04 2_0500_tunnel04 3_0000_tunnel04
El primer LOD (el de mayor detalle) para tunnel04 será visible desde 0m a 100 metros, el segundo LOD será visible desde 100 metros a 500 metros y el último LOD será visible de 500 metros en adelante. Este objeto no va a desaparecer más allá de 500 metros, y siempre se renderizará.
Nombres de las partes del modelo
A continuación se muestra una tabla con nombres de partes predeterminados. Si una parte del objeto no se ajusta a cualquiera de estos, puede utilizarse cualquier nombre lógico en su lugar.
| Objeto | Nombre | Nota |
|---|---|---|
| Locomotora | locomotive | Recomendado |
| Tender | tender | Recomendado |
| Coche de pasajeros | coach | Recomendado |
| Vagón de mercancías | wagon | Recomendado |
| Puerta | door##_? | Recomendado |
| Peldaño | step##_? | Recomendado |
| Rueda | wh## | Recomendado |
| Bogie | bo## | Recomendado |
| Rueda de un bogie | bo##wh## | Recomendado |
| Carga de carbón | coal | Recomendado |
| Nivel externo de combustible | fuel_level_? | Recomendado |
| Carga suelta (grano, arena...) | freight | Recomendado |
| Carga en bloque (caja, contenedor...) | bulk | Recomendado |
| Pantógrafo | panto## | Recomendado |
| Conjunto de elementos de una matrícula de longitud ## | primarydigits## | Obligatorio |
| Luces de cabeza en marcha adelante | lights_fwdhead | Obligatorio |
| Luces de cabeza en marcha atrás | lights_revhead | Obligatorio |
| Luces de cola en marcha adelante | lights_fwdtail | Obligatorio |
| Luces de cola en marcha atrás | lights_revtail | Obligatorio |
| Objeto sombra | shadow_nnnnn | Obligatorio |
| Objeto visualizado únicamente de día | fx_day | Obligatorio |
| Objeto visualizado únicamente de noche | fx_night | Obligatorio |
