trensim.comSimulación Ferroviaria
   

Trensimpedia :: Simulación Ferroviaria.
 
 

:: Entrar

RS:Consideraciones generales de creación en RS

De TrenSimpedia

(Diferencias entre revisiones)
(Shaders FX)
(Shaders FX)
Línea 149: Línea 149:
! Shader !! Descripción !! Ejemplos de uso
! Shader !! Descripción !! Ejemplos de uso
{{Fila_Tabla}}
{{Fila_Tabla}}
-
|'''StencilShadow'''||This shader is used specifically for the in-game stencil shadows. For this shader to function correctly, there are strict guidelines which must be adhered to when authoring shadow shapes. Please see authoring guides.||Stencil shadows
+
|'''StencilShadow'''||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 [[RS:Sombras_dinámicas_en_RS|Sombras dinámicas en RS]].||Elementos patrones de sombras de los objetos.
{{Fila_Tabla}}
{{Fila_Tabla}}
-
|'''TrainFlora'''||These are solely lit by ambient lighting (no diffuse lighting), and can have viewing facing properties.||Groups of leaves on foliage
+
|'''TrainFlora'''||Este shader está afectado únicamente por la luz ambiente (general), no por la luz difusa (direccional).||Grupos de hojas y vegetación.
{{Fila_Tabla}}
{{Fila_Tabla}}
|'''TrainViewFacingFlora'''||These are solely lit by ambient lighting (no diffuse lighting), and can have viewing facing properties.||Groups of leaves on foliage  
|'''TrainViewFacingFlora'''||These are solely lit by ambient lighting (no diffuse lighting), and can have viewing facing properties.||Groups of leaves on foliage  

Revisión de 20:56 28 mar 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

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. Son las denominadas Texturas estacionales.

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

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 FX y Shaders no-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 (diffuse).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 para adicionar luz sobre otros objetos mediante additive alpha.Proyecciones de focos de luz en el suelo o paredes.

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
StencilShadowEste 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.
TrainFloraEste shader está afectado únicamente por la luz ambiente (general), no por la luz difusa (direccional).Grupos de hojas y vegetación.
TrainViewFacingFloraThese are solely lit by ambient lighting (no diffuse lighting), and can have viewing facing properties.Groups of leaves on foliage
TrainUprightViewFacingFloraThese are solely lit by ambient lighting (no diffuse lighting), and can have viewing facing properties.Groups of leaves on foliage
LoftTexDiffThese are specific shaders used for generating in-game lofts. These shaders support transparency if required.Example use A brick wall
LoftTexDiffTransThese are specific shaders used for generating in-game lofts. These shaders support transparency if required.A tree-line
WaterCubeMapThis shader can be used to generate water surfaces.Water lofts
TrainEnvThis shader has a second pass reflection map.Shiny glass windows on a building (opaque)
TrainLightMapWithDiffuseThis shader allows for a second pass shadow map which allows the asset to have a pre-lit appearance. This helps the give the asset lighting more depth.Buildings and Stations
TrainBumpSpecEnvMaskShiny bumpy metalThe sides of a locomotive (slightly beaten in appearance)
TrainSpecEnvMaskShiny smooth metalThe sides of a locomotive (smooth in appearance)
TrainBasicObjectDiffuseFX shader version of the basic shaderSmall clutter objects (that do NOT require shadow-maps)
SkinDiffuseSkin shader specifically written for in-game characters. There are guidelines which must be followed when creating characters to ensure the character skeleton matches the expected skeleton within the shaderSkinned characters or wildlife
TrainSkyDomeSkin shader specifically written for creating dynamic skies.Skies

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