trensim.comSimulación Ferroviaria
   

Trensimpedia :: Simulación Ferroviaria.
 
 

:: 3.140.188.174 :: Discusión para esta IP :: Entrar

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

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 debe 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 con texturas de otro edificio y un vehículo de carretera texturas pueden compartir con otro vehículo de carretera.

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 a otro en cercanía, 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.

Trate de 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 página de textura 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.

Para ello nos vamos a poder apoyar en hasta 4 grupos de texturas por objeto:

  • Primavera - Los árboles podrían tener un follaje verde y flores
  • Verano - Representa las condiciones de iluminación normales (por defecto)
  • Otoño - Los árboles podrían 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".

No se producirá ningún cambio de grupos de texturas para un objeto durante una misma sesión o escenario en el juego.

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 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).
  • 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 ordenación alpha verdadera 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 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 mediante 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.

Shaders

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 primera 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 primera 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

LODs