trensim.comSimulación Ferroviaria
   

Trensimpedia :: Simulación Ferroviaria.
 
 

:: Entrar

RS:Consideraciones generales de creación en RS

De TrenSimpedia

Revisión a fecha de 08:26 8 abr 2009; Pere (Discusión | contribuciones)
(dif) ← Revisión anterior | Revisión actual (dif) | Revisión siguiente → (dif)

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

Icono de en curso

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:

PrimaveraBase (Verano)OtoñoInvierno
VegetaciónHojas "jóvenes"" y floresFollaje exuberanteHojas amarillentas y secasRamas cubiertas de nieve
EdificiosningunaTextura normalningunaEdificio cubierto de nieve en tejados y balcones
VehículosningunaTextura normalningunaninguna
TerrenoningunaTerreno normalningunaTerreno 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
TexEste shader no está afectado por la luz (falta de luz) nunca se oscureInterior de coches de viajeros, y ventanas de edificios por la noche (opacas).
TexDiffEste 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.
BlendATexDiffEste shader actual igual que TexDiff, pero además usa el canal alpha para generar transparencias degradadas mediante blending alpha.Ventanas de los trenes.
AddATexEste 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.
SubtractATexDiffEste 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.fxEste 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.fxEste shader está afectado únicamente por la luz ambiente (general), no por la luz difusa (direccional).Grupos de hojas y vegetación.
TrainViewFacingFlora.fxEste 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.fxEste 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.fxEste shader se usa para texturar objetos procedurales (lofts) generados por el juego.Un muro de piedra, vías, carreteras...
LoftTexDiffTrans.fxEste 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.fxEste shader se usa para generar superficies de agua.Rios, lagos...
TrainBasicObjectDiffuse.fxVersión FX del shader básico TexDiffObjetos en general (que NO requieren mapas de sombras). Se recomienta su uso generalizado cuando no es necesaria ninguna característica especial.
TrainEnv.fxEste 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.fxEste 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.fxPermite asignar al objeto mapa de normales (bump), especulares y de reflexión.Metales brillantes en relieve, laterales de locomotoras (con apariencia irregular)
TrainSpecEnvMask.fxPermite asignar al objeto mapa especular y de reflexión.Metales brillantes lisos, laterales de locomotoras y coches modernos (con apariencia regular)
SkinDiffuse.fxShader de piel especialmente desarrollado para los personajes en el juego.Piel de personas o animales.
TrainSkyDome.fxShader 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.

ObjetoNombreNota
LocomotoralocomotiveRecomendado
TendertenderRecomendado
Coche de pasajeroscoachRecomendado
Vagón de mercancíaswagonRecomendado
Puertadoor##_?Recomendado
Peldañostep##_?Recomendado
Ruedawh##Recomendado
Bogiebo##Recomendado
Rueda de un bogiebo##wh##Recomendado
Carga de carbóncoalRecomendado
Nivel externo de combustiblefuel_level_?Recomendado
Carga suelta (grano, arena...)freightRecomendado
Carga en bloque (caja, contenedor...)bulkRecomendado
Pantógrafopanto##Recomendado
Conjunto de elementos de una matrícula de longitud ##primarydigits##Obligatorio
Luces de cabeza en marcha adelantelights_fwdheadObligatorio
Luces de cabeza en marcha atráslights_revheadObligatorio
Luces de cola en marcha adelantelights_fwdtailObligatorio
Luces de cola en marcha atráslights_revtailObligatorio
Objeto sombrashadow_nnnnnObligatorio
Objeto visualizado únicamente de díafx_dayObligatorio
Objeto visualizado únicamente de nochefx_nightObligatorio