RS:Consideraciones generales de creación en RS

De TrenSimpedia

última version al 08:26 8 abr 2009

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.

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.

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:

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.

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.

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.

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.

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.