Traducción del documento FS FACTS extraído de wings.ark.com
FSFacts, extraído de las páginas de Justin Tyme Referencia de Diseño de Escenarios
FS Facts Copyright © 1996-1997 Konstantin Kukushkin. Todos los derechos reservados
Traducción © 1999 Joan Josep González Figueras
Contenido
Introducción
Como se almacenan los
Escenarios
Como funciona la librería de
Escenarios
Como funcionan los Boosters
en CD-ROM (Cachés)
Como el MSFS visualiza los Escenarios
Como el MSFS dibuja las Texturas
Como el MSFS dibuja los Colores
Como el MSFS dibuja los objetos 3D
Introducción
Este documento discute algunos
principios de trabajo del Microsoft Flight Simulator "MSFS" y se centra en
como MSFS procesa los escenarios. No es una referencia completa, pero es una colección de
hechos y suposiciones que pueden ser de interés a muchos usuarios y/o diseñadores de
escenarios.
Este documento es conveniente para tanto
diseñadores de escenarios como para otros usuarios, ya que principalmente contiene
información general que puede ser de interés (y uso) para ambos grupos. A veces este
documento contiene notas "técnicas", como números hexadecimales. Los que no
sean diseñadores no se asusten por esto. Estos detalles se dan para no duplicar
pararrayos enteros en el documento orientado a diseño de escenarios.
volver al contenido
Como se
almacenan los Escenarios
Esto es un informe descriptivo de como
se almacenan los escenarios. Debería ser suficiente para entender el resto de este
documento. Una descripción mas detallada (pero técnica) está disponible en FS5STRUC y
documentos para distintos compiladores de escenarios.
El mundo del MSFS está a menudo
referenciado como "escenario". Incluye todo lo que no esta directamente
influenciado por el usuario - paisaje y objetos que ves, ayudas de navegación, otros
aviones, etc. Algunos datos auxiliares que usa MSFS - como desviaciones magnéticas,
mensajes ATIS, etc. también dependen de los escenarios. Por el contrario, el propio
avión, aviones que se ven en multiplayer o en los modos de entretenimiento, o aventuras
del MSFS no pertenecen a los escenarios - son controlados por el usuario o por módulos
del MSFS. Por consiguiente el escenario es un entorno en donde tiene lugar una acción.
MSFS es flexible y permite reforzar su
mundo. Estos refuerzos son llamados 'escenarios', a veces causando confusión. Un
escenario puede ser tan pequeño como una simple pista, o tan grande como todo el mundo.
Así, esta definición es un poco intuitiva.
Por ejemplo, "Default World"
es un escenario del mundial. Cada una de las 7 metro arreas pueden verse como escenarios
separados. Cada una de ellas se puede eliminar (casi) sin efectos colaterales, en
particular sin afectar otras partes del mundo. He puesto la palabra "casi"
porque todos los aeropuertos en el menú World/Airports están situados en un fichero
separado, con lo que aeropuertos eliminados seguirían en la lista - o el fichero tiene
que ser eliminado completamente. Seleccionándolos pondría el avión en el medio del aire
- y el aeropuerto, por supuesto, no estaría allí. Esto muestra uno de los muchos
problemas causados por esta flexibilidad. No obstante, sus ventajas son mucho mas
importantes, ya que nos permite mejorar el mundo del MSFS añadiendo escenarios - tanto
comerciales como freeware.
Los escenarios consisten en ficheros de
escenarios (*.BGL) y a menudo otros ficheros. Los ficheros BGL contienen la mayor parte de
la información sobre el escenario, mientras que los otros ficheros solo son referenciados
desde los ficheros BGL. Un escenario puede consistir en múltiples ficheros BGL. Esto es
principalmente por razones de ser - para mejorar la ejecución del MSFS, para superar
algunos límites del MSFS o para permitir además customizaciones (normalmente borrando
ficheros BGL no requeridos).
Los ficheros de escenarios contienen
distintas secciones, las cuales tienen distintos tipos de información. Aquí, solo
hacemos una breve e incompleta descripción de estas secciones.
Los escenarios SYNTH(sintéticos)
(actualmente consisten en 6 secciones con distintas resoluciones) es una base de datos de
TILES. La tierra en el MSFS esta dividida en 8192x4096 cuadrados, y el escenario synth
describe como tiene que ser cada cuadrado. El escenario synth es parecido al paisaje o
vista en el tan popular juego SimCity. Muchas líneas de costa o cordilleras fuera de
arreas metropolitanas son buenos ejemplos de escenario synth - los cuadrados son
fácilmente reconocibles. El escenario synth nos permite definir paisajes llanos,
montañas sin textura cuadradas, ciudades estándar y líneas de costa.
Otra función importante del escenario synth es la de definir la
altitud del suelo sobre MSL (Nivel medio del mar).
Mientras que el escenario synth no permite diseñar escenarios
detallados y precisos, es muy conveniente para cubrir grandes partes de terreno debido a
sus relativamente pequeños requerimientos de disco, poco impacto en procesador, y
también importante, facilidad de diseño.
Casi todo el mundo del MSFS esta definido usando solamente
escenarios synth. El mundo en disco del FS5.0/5.1 esta solamente definido en bloques de
32x32 tiles, por esta razón es tan insuficiente. El mundo del FS5.1 en CD y del FS6
contiene escenarios synth mucho mas detallados en el CD, por lo que las líneas de costa y
el terreno es mas detallado.
Ya que una esfera no puede ser cubierta (aun así casi) con
cuadrados, el modelo de tierra en el MSFS no es una esfera, es un cilindro torcido. Los
polos de la tierra no están en el mundo del MSFS, y no se puede ir mas allá de 89 grados
30 minutos tanto al norte como al sur en latitud.
Escenario VISIBLE (o PROCESABLE)
contiene la mayor parte de las otros rasgos y objetos. Al contrario del escenario synth,
que está definido por un juego de datos, el escenario visual se define por una especie de
("código") programa que da instrucciones al MSFS de como y que visualizar.
Muchos comandos que usa son bastante simples - como 'dibuja un polígono' - pero hay
comandos complejos para testear distintas condiciones, visibilidad, etc. Puntos, líneas y
polígonos se llaman primitivas (gráficas), porque son elementos básicos usados para
construir objetos mas complejos.
El rico conjunto de instrucciones hace
muy flexible el escenario visual en términos de lo que puede visualizar, pero también
mas difícil de programar y requiere mucho mas espacio en disco y potencia de proceso. Por
esta razón, solo arreas relativamente pequeñas pueden ser cubiertas mediante escenarios
visuales. En el FS5.0 y la versión en disquetes del FS5.1, solo tiene escenario visual en
7 áreas metropolitanas. La versión en CD del FS5.1 añade unos pocos 'Pedacitos' en el
mundo. El FS6 añade muchos mas escenarios locales y carreteras y ríos alrededor del
continente americano.
El escenario visual es también el
responsable de algunas funciones que van mas allá de simplemente dibujar escenarios. Una
de estas funciones es la detección de colisiones. Debido a que los objetos son
representados básicamente por comandos que dibujan sus lados, el MSFS no tiene forma de
determinar una colisión entre el avión y un objeto, como una montaña. Es
responsabilidad del escenario el determinar si el avión está 'dentro' de la montaña y
de notificar al MSFS de ello mediante una colisión. Esto permite una forma fácil de
evitar colisiones con objetos visuales - simplemente cerrando todas las vistas y ventanas
de mapa y volar a ciegas. Sin ventanas de vistas, el código del escenario visual no será
ejecutado por lo que no se detectarán colisiones. La única cosa a tener en cuenta seria
no colisionar con el suelo.
Otra función semejante incluye el
determinar el tipo de terreno (liso, rugoso o agua), definiendo corrientes termales y
reaccionando a distintas situaciones como complejidad de escenarios o textura del
terreno. Muchos escenarios freeware, por ejemplo, no chequean el flag (opción) terreno
con textura, en consecuencia obligan a que el terreno siempre tenga textura.
El lenguaje que se usa para definir
escenario visual (a menudo llamado SDL - Scenery Description Language) es complejo y
permite implementar muchos efectos interesantes, como objetos animados o luces controladas
por el piloto.
El escenario DINÁMICO
define objetos en movimiento, como otros aviones o camiones de gasolina. Cada objeto del
escenario dinámico tiene una especie de programa que le dice lo que tiene que hacer. Sin
embargo, el lenguaje es mucho menos flexible que el SDL. Solo permite visualizar unos
pocos tipos de objetos predefinidos y no permite objetos inteligentes que pudieran 'ver'
otros tráficos y reaccionar en consecuencia. Asimismo, existen ciertos problemas con los
objetos dinámicos que interfieren con el escenario visual (mas sobre esto en FS_PRO)
SECCION 16 contiene
muchos tipos de estructuras de datos. Contiene mascadores de posiciones, zonas horarias y
información de pistas para la función LandMe (Aterrízame). Aunque las pistas se definen
en el escenario visual, esta información solo se usa para visualizarlas. Por eso son
necesarios datos adicionales para la función LandMe. Redundancias como esta son usadas a
menudo en el MSFS, muchas son para mejorar la ejecución.
Asimismo, sección 16 puede contener
pequeñas porciones de código SDL. Al contrario que el código en la sección 9, no se
puede usar para visualizar objetos. Se usa solo para definir pequeñas superficies
elevadas, como cubiertas de portaaviones, esto no se puede implementar mediante escenario
synth. La ventaja del código de la sección 16 es que no requiere ninguna de las ventanas
de Vistas sean abiertas.
Otras secciones definen ayudas de
navegación, mensajes ATIS, entradas en el menú World|Airports etc. También existen
secciones especiales que son usadas para la variación magnética, exclusión de ficheros
y parecidos.
volver al contenido
Como funciona la librería
de Escenarios
Situaciones y prioridades de todos los
escenarios usados por el MSFS se almacenan en la librería de escenarios. También
contiene punteros los performance boosters del CD-ROM e información adicional.
MSFS usa la librería de escenarios para
seleccionar los ficheros BGL a usar. Mientras vuelas, periódicamente chequea todos los
ficheros/directorios de la librería de escenarios. Cada fichero de escenario empieza con
una cabecera que contiene los bordes del área cubierta por ese fichero. MSFS utiliza un
fichero de escenario solo si el avión esta dentro de esos bordes definidos en la
cabecera.
Después, cuando MSFS interpreta el
contenido de los ficheros de escenarios, se hacen chequeos adicionales de visibilidad para
determinar, que partes del escenario de objetos deberían estar visibles/disponibles. Sin
embargo, MSFS nunca interpreta el contenido de ficheros de escenarios rechazados porque el
avión esta fuera de sus limites definidos en la cabecera. En particular, objetos de estos
ficheros nunca son visibles incluso si lo debieran ser a causa de sus dimensiones y las
radioayudas no están disponibles incluso aunque lo debieran ser por sus rangos de
alcance. Por esta razón, muchas cabeceras de BGL definen limites para incluir ciertas
áreas no cubiertas por el escenario, pero en donde el escenario debería ser aun visible
y sus radioayudas disponibles.
Los ficheros de escenarios en la
librería de escenarios están organizados por niveles. Cada nivel consiste en un path (se
permiten comodines) a uno o mas ficheros de escenarios, y otras opciones. Existen
dos niveles especiales en la librería de escenarios: "Default World" y
"Default World - Metro". No se pueden cambiar o eliminar estos niveles, pero se
pueden cambiar sus prioridades.
"Default World" contiene el
escenario sintético por defecto (baja resolución) del MSFS. Este apunta al
directorio principal SCENERY. Ya que contiene solo escenario sintético, normalmente
debería tener la prioridad mas baja.
"Default World - Metro" tiene
las 7 áreas de escenarios por defecto así como muchos ficheros de escenarios auxiliares
usados por el MSFS (desviación magnética, los aeropuertos del menú World/Airports,
zonas horarias, etc.). Apunta al directorio principal SCENERY. Usuarios perezosos también
instalan escenarios descargados en este directorio.
El orden de los niveles determina las
prioridades de los ficheros de escenarios. MSFS sigue este orden mientras procesa las
distintas secciones de los ficheros de escenarios (radioayudas, escenario sintético,
escenario visual, etc.).
Un tipo especial de ficheros de
escenarios son los ficheros de exclusión. Un fichero de exclusión da instrucciones al
MSFS para ignorar objetos del escenario visual y algunas radioayudas que estén definidas
en niveles debajo del nivel en donde reside el fichero de exclusión y localizadas dentro
del área definida en el fichero de exclusión. Los ficheros de exclusión afectan al
escenario visual, VORs, NDBs y mensajes ATIS. No afectan al escenario sintético (synth),
escenario dinámico y estructuras de datos de la sección 16, incluyendo marcadores de
posición y superficies elevadas.
Los ficheros de exclusión se usan
normalmente para resolver conflictos en escenarios como objetos o radioayudas duplicados.
Las situaciones en la librería de
escenarios solo afectan a las prioridades (=orden de dibujo) entre objetos del mismo tipo.
Por ejemplo, el orden de dibujado de los polígonos de tierra pueden ser influenciados,
pero el escenario visual siempre se dibuja encima del escenario sintético, sin tener en
cuenta las prioridades puestas en la librería de escenarios, mira la sección "Como
el MSFS dibuja los escenarios" para tener mas información sobre prioridades.
La librería de escenarios se almacena
en el fichero WORLD.VIS en el directorio principal SCENERY del MSFS. Se puede modificar
mediante la opción de menú "World|Scenery Library" (FS6) o
"Scenery|Scenery Library" (FS5.1). MSFS tiene un bug que puede provocar que el
fichero WORLD.VIS sea dañado o incluso vaciado completamente después de ser cambiado.
Con lo que siempre deberías hacer una copia de seguridad antes de modificarlo.
El procedimiento para modificar la
librería de escenarios se describe bien en el manual del MSFS. Solo añadir unas
observaciones.
Las prioridades de los niveles son
determinadas por los números de nivel. La prioridad del escenario sintético decrece al
incrementar el numero de nivel. Por el contrario, la prioridad de los escenarios visuales
se incrementa al incrementarse el numero del nivel. Sin embargo, a causa de conflictos
entre escenarios del escenario visual o radioayudas se resuelven normalmente mediante
ficheros de exclusión, que solo afectan números de nivel superiores, los niveles con
numero inferior normalmente se dice que tienen mayor prioridad.
De acuerdo con mis observaciones, el
tipo de nivel no afecta ninguna prioridad y solo se usan para la opción Auto Arrange.
Esta opción ordena los niveles de acuerdo con este tipo de nivel.
Los ficheros de escenario a los que se
hace referencia en los niveles se deben almacenar usando una estructura especial de
directorios. El directorio en donde estará el escenario debe tener dos directorios,
SCENERY y TEXTURE (no TEXTURES!). Todos los ficheros de escenario (*.BGL) deben ser
puestos en el subdirectorio SCENERY. Todos los ficheros de texturas (*.R8), paletas
(*.PAL) y haze (*.HAZ) deben ser puestos en el subdirectorio TEXTURE. Cuando se añada el
escenario a la librería de escenarios, se debe especificar el camino (path) a los
ficheros del subdirectorio SCENERY. MSFS NO deja añadir escenarios que su subdirectorio
ultimo no sea otro que SCENERY. De forma similar la opción "Search for Scenery"
(Buscar escenarios) no busca en ningún directorio que no acabe en "\SCENERY".
Los caminos (paths) en el WORLD.VIS se guardan sin el ultimo subdirectorio 'SCENERY'.
Una excepción a las reglas anteriores
son las texturas con nombre SEED??.R8. Estas siempre deben colocarse en el directorio
principal TEXTURE del MSFS. La razón de esto es que estos ficheros de texturas son usados
por el escenario sintético. Debido a que el escenario sintético circundante se almacena
en un array antes de ser dibujado, no hay información disponible sobre la localización
del fichero de la textura en tiempo de dibujo.
volver al contenido
Como funcionan los
Boosters en CD-ROM (Cachés)
El sistema de escenarios por si solo no
sabe nada de especial sobre el escenario en CD-ROM. Un escenario en CD-ROM está
representado por un nivel que apunta a un directorio en el disco duro, como cualquier otro
escenario. La diferencia con un nivel de un escenario normal es, este directorio (también
llamado "caché") normalmente no tiene ningún fichero. En cambio, se usa un
llamado propulsor (booster) de ejecución del CD-ROM. Un booster (propulsor) de ejecución
es una especie de 'agente silencioso' que sabe áreas cubren los ficheros de escenarios
que están en el CD y constantemente controla la localización del avión. Cuando el
avión entra en un área cubierta por algún fichero de escenario del CD, el booster copia
este fichero al directorio caché. Cuando el avión sale del área cubierta por el fichero
de escenario, este fichero es (normalmente) borrado del directorio cace. El procesador de
escenarios desconoce estos movimientos. Solo se le ordena releer ficheros de escenarios,
por lo que los cambios tienen efecto. De forma similar, el booster de ejecución no conoce
casi nada sobre lo que hace el procesador de escenarios. Continuará copiando ficheros de
escenarios incluso si el nivel de escenario correspondiente esta desactivado.
Cada booster tiene un juego de
parámetros que se pueden cambiar en la ventana de la librería de escenarios. El source
path es el nombre del directorio en el CD ("directorio origen") que contiene los
ficheros de escenario y texturas. Se almacenan mediante una estructura de subdirectorios
especial. El directorio origen también tiene un fichero que se llama BSTINFO que tiene
información de las áreas cubiertas por cada fichero BGL. Desde el fichero BSTINFO, el
booster puede obtener toda la información necesaria sin leer ningún fichero de
escenario. En el FS5.1, un directorio origen también debe contener un fichero BOOSTER,
que es una copia del fichero BOOSTER del directorio principal del FS5.1.
El path del cache es el nombre del
directorio en el HD en donde el booster copiara los ficheros. Este directorio (también
llamado "directorio cache") debe contener los subdirectorios SCENERY y TEXTURE.
El directorio SCENERY también debe ser puesto en algún nivel de escenario, si no el FS
no "verá" los ficheros de escenario elegidos por el booster.
El directorio cache debe tener una copia
del fichero BSTINFO de su correspondiente directorio origen. En el FS6 respecto del FS5.1,
también debería tener el fichero BOOSTER.DLL respecto BOOSTER, que es la copia del
fichero con el mismo nombre en el directorio MODULES correspondiente al directorio
principal del FS.
La estrategia de modificación del cache
determina en que momentos los ficheros de escenarios son copiados del CD. Cuando está en
"Automático", el FS mira la posición del avión y copia automáticamente
los nuevos ficheros de escenarios en el directorio cache cuando se necesiten. Este a
menudo es el método mas conveniente, ya que el proceso de modificación es completamente
transparente. Sin embargo, el copiado de los ficheros de escenarios provoca una pequeña
pausa, especialmente cuando se copia desde un CD-ROM lento. Estas pausas pueden llegar a
ser bastante molestas en fases criticas del vuelo, como la aproximación final.
El método "Manual" hace que
en el FS salga el mensaje "Update Scenery" cuando el avión entra en una nueva
área y ficheros nuevos de escenario deben ser copiados. El usuario debe pulsar la barra
de espacio para lanzar el proceso de copiado. Este método requiere de alguna interacción
con el usuario, pero al mismo tiempo previene pausas inesperadas - solo ocurren cuando el
usuario lo permite.
El método "Semi-Automático"
funciona como el "Automático" cuando el avión se encuentra por encima de 750
pies AGL, y como el método "Manual" cuando esta por debajo. Esto previene
pausas inesperadas en fases criticas del vuelo, como la aproximación final, que
normalmente suceden a baja altitud.
La opción tamaño del Cache limita el
espacio en disco ocupado por los ficheros del directorio cache. Si se esta a punto de
superar este tamaño, el FS borra los ficheros del directorio cache que no se usarán mas.
El método de vaciado del cache
determina si el FS deja los ficheros en el directorio cache cuando no se usen o cuando
termine el FS. "Clean on exit" (Limpiar al salir) provoca que todos los ficheros
que no se van a usar sean eliminados. "Do not Clean on exit" (no limpiar al
salir) deshabilita el limpiado.
Por que el FS utiliza los boosters en
vez de acceder directamente al CD? La razón principal es por ejecución. Asimismo,
implementar el mecanismo de los boosters fue más fácil que re-escribir el motor de los
escenarios para lograr un incremento similar de ejecución.
El motor de los escenarios trabaja
periódicamente leyendo y procesando TODOS los ficheros de escenarios de los niveles
activos. Teniendo que acceder a miles de ficheros de escenarios requeriría un numero
enorme de accesos a disco y tiempo de proceso, incluso si estos ficheros son
inmediatamente descartados por cubrir áreas completamente distintas. También,
tener que almacenar una gran lista de ficheros consumiría demasiada memoria.
Un booster actúa como un filtro,
dejando solo los ficheros de escenarios para el motor de escenarios que son relevantes
para el área que se esta sobrevolando. Usando la información del correspondiente fichero
BSTINFO, conoce que fichero de escenario cubre que área sin tener que acceder a cada
fichero. Pro consiguiente, los boosters en CD-ROM contribuyen mucho a la ejecución del
FS, incluso si el procedimiento parece ineficiente a primera vista.
volver al contenido
Como
el MSFS visualiza los Escenarios
El MSFS simula el movimiento
visualizando series de instantáneas del escenario, parecido a la TV. Cada instantánea de
estas se llama frame (marco). El numero de frames visualizadas en un segundo se llama
frame rate (velocidad). Como cada frame se calcula por separado, el frame rate (o fps)
depende mucho del numero de cálculos que tiene que hacer el MSFS para completar cada
frame. En el mismo PC, el frame rate puede ser muy alto en áreas con escenarios simples,
como solo escenario sintético, y muy bajo en áreas con escenario complejo con muchos
objetos con textura.
La necesidad de un alto frame rate ha
llevado a muchos compromisos razonables al motor de gráficos del MSFS. Estos compromisos
reducen gratamente el numero de cálculos necesarios, pero impone muchas limitaciones a lo
que se puede hacer mediante este motor. No se puede implementar cualquier tipo de vista o
paisaje como un escenario del MSFS.
Una de las ideas básicas del motor de
gráficos del MSFS es que no hay superficies ocultas entre objetos distintos. Todos los
objetos son tapados parcial o totalmente son sobre-pintados por los objetos que los
cubren. Este método permite un rendering realístico del escenario en muchos casos sin
ninguna necesidad de cálculos lentos y complejos necesarios para una 'verdadera'
ocultación de superficies.
El FS6 no dibuja las frames directamente
en la pantalla, si no que lo hace en un buffer de memoria especial. Mientras una frame es
visible en la ventana, el FS6 dibuja la siguiente en el buffer. Cuando la siguiente frame
esta acabada, el FS6 copia el contenido del buffer a la ventana y empieza a dibujar la
siguiente. Esta técnica asegura que el proceso de sobre-pintado de objetos ocultos no es
visible. Solo se usan 256 colores para dibujar las frames en el buffer interno, incluso si
el adaptador gráfico esta en modo HiColor o TrueColor.
El FS5 utiliza dos páginas de
visualización para obtener el mismo efecto.
El MSFS nunca borra el buffer de frames
antes de dibujar otra frame. Se asume que el escenario ocupa toda la vista de la ventana y
que es responsabilidad del diseñador de escenarios asegurar esto. Esto no es muy difícil
ya que el escenario por defecto del MSFS ya tiene el mundo entero. La única fuente
posible de problemas que conozco son los tiles sintéticos transparentes (ver abajo).
Cuando el MSFS empieza a dibujar una
nueva frame, empieza por el cielo. Luego, visualiza todos los niveles de nubes sobre el
observador. Esto significa, por ejemplo, que en el MSFS es imposible ver montañas con
cimas cubiertas por nubes - las montañas se visualizan mas tarde y se sobre-pintan
cualquier nube.
Entonces, se visualizan las partes
planas del escenario sintético. La descripción mas fácil de entender de los escenarios
sintéticos que conozco viene con el BGLGEN, y la descripción mas completa viene con el
FSASM.
Las tiles sintéticas no se dibujan
inmediatamente. En cambio, los atributos de las tiles sintéticas que están lo
suficientemente cerca del avión se guardan en un array de dos dimensiones. Cuando dos
ficheros de escenario distintos (en conflicto) definen la misma tile, el segundo fichero
simplemente sobrescribe el correspondiente elemento del array, en vez de dibujar la tile
por segunda vez. Una vez que todos los ficheros de escenarios se han leído y procesado,
se dibujan las tiles planas mediante la información del array.
Aunque cada tile tiene su propia
altitud, el MSFS visualiza todo el escenario sintético como un solo plano. La altitud
relativa del avión encima de este plano es determinada por la altitud encima de la tile
que esta debajo del avión. A medida que el avión se mueve, aparecen debajo otras tiles
con a veces distintas altitudes. Entonces , el MSFS ajusta la altitud del plano para
mantener la altitud relativa correcta respecto de la tile que esta debajo. Esto provoca
que el terreno "flote" hacia arriba o hacia abajo, dependiendo del cambio en la
elevación.
En el MSFS, existen dos formas para
especificar la altitud del escenario visual de objetos. Para cada objeto, se puede
especificar su altitud del terreno, o su altitud absoluta sobre el nivel del mar. La
altitud absoluta se usa para objetos como pistas, en donde guardar la altitud relativa
correcta del avión es mas importante que una apariencia visual que guste. Por esta
razón, algunos objetos no flotan arriba y abajo con el terreno, si no que a veces
aparecen flotando en el aire o enterrados bajo el suelo. Altitud absoluta se usa también
en objetos que no están en el suelo, como globos aerostáticos.
Casi todos los objetos se ponen a la
altitud del terreno. Siempre aparecen en el suelo, pero también flotan arriba y abajo con
el suelo cuando la elevación de la tile cambia.
Ya que el escenario sintético cubre
completamente todo el mundo, los diseñadores de escenarios normalmente no se tienen que
preocupar de cubrir la vista entera de la ventana - se cubre automáticamente por el cielo
y el escenario sintético. Sin embargo, hay una excepción.
Si una tile sintética esta totalmente
cubierta por polígonos de terreno u otros objetos, el usuario nunca podrá verla.
Entonces seria casi razonable mandar al MSFS no dibujar esa tile, con lo que se
optimizaría en frame rate. Existe un tipo de tiles especial "transparente" que
nos permite hacer esto. Estas tiles nunca se dibujan, solo se usan para especificar la
correcta elevación del terreno. Es muy importante el asegurarse de que estas tiles
se cubren completamente, si no las frames anteriores no se repintarían completamente y
restos de objetos fluctuando podrían aparecer en las áreas no cubiertas. Quizás una
buena idea para el escenario del Triángulo de las Bermudas :-)
Finalmente, se visualiza el escenario
visual. El escenario visual contiene todos los objetos visibles, carreteras, ríos,
polígonos del terreno, etc. excepto objetos definidos como escenario sintético.
El escenario visual contiene tres tipos
de objetos: Objetos 2-D, objetos de prioridad 2-D y objetos 3-D. El MSFS utiliza distintos
algoritmos para cada tipo de objeto para determinar el orden en que se pintan. Cuando se
visualiza el escenario visual, el MSFS primero dibuja todos los objetos 2-D de todos los
escenarios, después todos los objetos con prioridad 2-D de todos los escenarios y
finalmente todos los objetos 3-D de todos los escenarios.
La mayor diferencia entre objetos 2-D y
3-D es que el orden de dibujado de los objetos 2-D no depende de la posición del
observador.
Los objetos 2-D se dibujan en el orden
en que aparecen en los ficheros de escenarios. Los objetos 2-D de múltiples ficheros de
escenarios se dibujan en el orden que determina la librería de escenarios. El usuario
puede cambiar este orden cambiando los niveles en la librería de escenarios.
Muchos objetos "planos" del
MSFS, como carreteras, ríos, pistas de rodaje, polígonos de tierra, lagos y fuel
"boxes", están hechos como objetos 2-D.
Todos los objetos 2-D con prioridad
tienen un parámetro "nivel" (layer). Estos "niveles" determinan el
orden de dibujado. Los objetos de todos los escenarios con nivel 0 se dibujan primero, o
sea que tienen la menor prioridad, los objetos con el nivel mas alto se dibujan los
últimos, o sea tienen la mayor prioridad.
La ventaja de los objetos 2-D con
prioridad es que el orden de dibujado no depende del orden de los ficheros de escenarios.
Esto también es la mayor desventaja, ya que el usuario no tiene la posibilidad de
solventar conflictos entre escenarios excepto desactivando los escenarios en conflicto.
En el escenario por defecto las pistas y
muchos añadidos están implementados como objetos 2-D con prioridad. El escenario
(comercial) Europa1 utiliza objetos 2-D con prioridad en todas sus texturas del terreno,
con lo que dificulta el añadir polígonos de terreno.
Los objetos 3-D se dibujan en un orden
que se supone asegura que los objetos mas distantes sean sobre-impresos (tapados) por los
que están mas cerca. Cada objeto tiene un "punto de referencia", y los objetos
se ordenan para dibujarse de acuerdo con la distancia entre el observador y sus puntos de
referencia.
Mientras que este método permite un
pintado realístico del escenario en muchos casos, crea dificultades cuando la distancia
entre objetos 3-D es comparable a sus tamaños. Por ejemplo, es casi imposible hacer
ciudades con colinas en el MSFS - el motor gráfico no sabría determinar el orden correcto
de pintado.
Las montañas y edificios del escenario
sintético, objetos del escenario dinámico, otros aviones y el propio avión desde vistas
externas se ordenan y visualizan con los objetos 3-D.
Después de dibujar el escenario visual,
el MSFS dibuja todos los niveles de nubes situados debajo del observador. Esto hace
imposible, por ejemplo, ver picos de montañas encima de nubes - todas las montañas
debajo del horizonte se taparan por las nubes.
El mundo en el MSFS es un poco complejo
y tener que visualizar todos los objetos visibles llevaría hacia un inaceptable frame
rate. Por esta razón, cada objeto visible tiene un llamado rango de visibilidad y solo se
pinta si la distancia hasta el observador no supera este rango.
volver al contenido
Como el
MSFS dibuja las Texturas
El MSFS usa ficheros de texturas (*.R8) para dibujar todos los
bitmaps que aparecen en el escenario (las ventanas Vista 1 y 2 y el Mapa). Los ficheros de
texturas pueden tener extensiones distintas de ".R8".
Los ficheros de texturas se usan en los ficheros de escenarios
(*.BGL) y aviones (*.AIR). Por ejemplo, un escenario que visualiza un polígono
de terreno
con textura normalmente tiene dos comandos para esta operación: el primero hace que el
MSFS lea un fichero de una textura especifica y el segundo hace pintar el MSFS un
polígono con la textura "actual".
El MSFS guarda texturas en memoria (cache), con lo que elimina la
necesidad de acceder al disco cada vez que el MSFS necesita una textura especifica. Sin
embargo, si un escenario intenta leer mas texturas de las que caben en la memoria
disponible, el sistema de cache no funciona muy bien. Para estos casos, el MSFS tiene un
"mecanismo de salvaguarda" que previene el leer mas de un fichero de textura por
frame. Este mecanismo previene al MSFS de pararse completamente en caso de escasez de
memoria, accesos a disco constantes pueden reducir el frame rate hasta un nivel
inaceptable.
Cada fichero de textura contiene una matriz de 256x256 píxeles. Si se
tiene que visualizar un bitmap mas grande, este se separa en múltiples ficheros de
texturas y cada textura se dibuja por separado. Por ejemplo, el aeropuerto de Meigs se
visualiza mediante dos ficheros de texturas.
Cada píxel se representa mediante un valor de 8-bits.
Este valor sirve como un índice en una tabla especial llamada 'paleta'. La
paleta contiene valores RGB para 256 valores posibles del píxel. Es usada por
la tarjeta de video para convertir los valores de los píxeles en colores
actuales.
En el MSFS, las entradas de la paleta se usan como
sigue:
0-115 Usados para visualizar escenario. La intensidad
varia de acuerdo con el momento del día para simular efectos de día/noche.
115-127 Usados para visualizar escenarios (iluminación,
etc.), algunos gauges y objetos de interface de usuario, como menús y cuadros
de dialogo. La intensidad no varia.
128-159 Usados para visualizar el panel de instrumentos.
La intensidad varia de acuerdo con la hora del día. Los colores dependen del
panel de instrumentos. Cuando por la noche se encienden las luces de los
instrumentos, estos colores se convierten en gradientes (no
disminución) del naranja y también son usados para visualizar la vista del
mapa.
160-191 Usados para visualizar el cielo, nubes y
tormentas. La intensidad varia de acuerdo con la hora del día. Los colores
160-175 tienen un componente rosa durante la salida y puesta del sol. Nótese
que el propio sol no es visible en el MSFS.
192-255 Usados para visualizar escenarios. La intensidad
varia conforme cambia la hora del día. Al contrario de los otros colores,
estas entradas de la paleta pueden ser redefinidas por el escenario para
obtener la paleta optima para dibujar texturas.
El MSFS guarda las paletas en ficheros de paleta
(*.PAL). Cada fichero de paleta contiene 256 valores RGB, una por cada entrada
de la paleta. Por otro lado, el MSFS usa solo una parte de estas entradas para
programar la paleta actual. Otros colores de la paleta son calculados por el
MSFS.
La paleta por defecto del MSFS esta almacenada en el
fichero FS5.PAL en el directorio principal TEXTURE. Desde este fichero de
paleta, el MSFS utiliza las entradas 0-115 y, si el escenario no usa cualquier
otra paleta, las entradas 192-255. Mientras que otras entradas en este fichero
también reflejan la paleta que usa MSFS, solo es una
"coincidencia". El MSFS las ignora.
El escenario puede ordenar al MSFS la
carga de una paleta customizada. De estos ficheros, el MSFS solo usa las
entradas de color 192-255.
Ya que la pantalla solo puede manejar
una paleta a la vez, existe una pequeña oportunidad de un conflicto de
paletas entre escenarios. Los escenarios hacen un "chequeo de área"
antes de leer la paleta. La paleta customizada se lee y las texturas se
dibujan solo si el punto de vista esta dentro de cierta área. Si áreas de
dos escenarios se cruzan, algunas texturas pueden tener colores incorrectos.
El FS6 y el FS5.1 en modo haze (niebla)
también necesitan un fichero haze que los acompañe (*.HAZ) para cada fichero
de paleta. Un fichero haze contiene una serie de 16x256 valores de píxel, 16
valores de substitución para cada valor de píxel. Cuando el MSFS dibuja
objetos, este reemplaza cada píxel con uno de sus valores substitutorios de
acuerdo con la distancia. Así, el primer valor de substitución es
normalmente el valor original del píxel, y el ultimo valor representa un
color gris.
En casi todos los polígonos
horizontales con textura, la intensidad del efecto haze varia de acuerdo con
la distancia de píxeles individuales. En todas las otras instrucciones, se
determina por la distancia al punto de referencia y no varia dentro de la
instrucción. Esto a menudo provoca que carreteras o ríos sin textura se
'vean' a través de la niebla cuando sus puntos de referencia se acercan al
punto de vista.
Al contrario de los ficheros de paleta
customizados, el MSFS siempre usa el fichero entero de haze (niebla) cargado
junto la paleta customizada. La razón de esto es que, el fichero por defecto
de niebla FS5.HAZ contiene algunos valores de substitución por encima de 192.
Debido a que los colores por encima de 192 son redefinidos por la paleta
customizada, se necesita una nueva tabla de substitución completa.
Cuando se visualizan texturas, el MSFS a
veces usa una técnica llamada 'suavizado de imágenes' para casi incrementar
la resolución de la textura. La resolución en ambas direcciones se
incrementa 4 veces, y los colores de los píxeles adicionales se obtienen
usando interpolación. Esto crea la ilusión de una transición suave entre
los píxeles de las texturas. Los colores interpolados se visualizan mezclando
píxeles vecinos en distintas proporciones. Por esta razón, imágenes de
texturas suavizadas parece que estén un poco oscurecidas.
El suavizado de imágenes solo funciona
si está activado en la opción de menú Options / Preferences / Display /
Scenery. Así mismo, el escenario debe contener el comando que permite
suavizar imágenes para operaciones de mapping (mapeo) con texturas.
volver al contenido
Como el MSFS dibuja los Colores
A pesar de la capacidad mapping de
texturas del MSFS, muchas superficies y todas las líneas y puntos no tienen
textura. El MSFS puede visualizar primitivas coloreadas uniformemente de una
forma muy realistica.
Aunque el MSFS trabaja en modo 256
colores requiriendo 8 bits/píxel, los colores del escenario son seleccionados
usando números de 16 bits. El byte alto selecciona una llamada paleta de
color, mientras que el byte bajo selecciona el color de esta paleta.
Hay 3 paletas distintas desde donde se
puede escoger el color. Estas paletas no se deben confundir con la paleta
hardware o ficheros de paleta del MSFS. Son mas bien un interface entre los
comandos de dibujado y la paleta hardware. Los colores en el MSFS no son
valores RGB usados para pintar píxeles, estos describen propiedades de las
primitivas a las que aplican. Por ejemplo, una cara de un edificio siempre
tiene el mismo color. Sin embargo, su intensidad varia de acuerdo a la
posición del sol y se vuelve negra por la noche, sin tener en cuenta su valor
RGB original. Al contrario de esto, las luces de final de pista retienen la
misma intensidad sin tener en cuenta la hora del día. Las sombras siempre
tienen color negro, pero es transparente - el suelo se sigue viendo bajo la
sombra.
El MSFS modifica los valores actuales RGB producidos por
especificaciones de color de distintas formas. Primero, la paleta hardware
cambia la intensidad de sus colores de acuerdo con la intensidad (simulada) de
la luz del sol o de la luna. Las entradas de la paleta no se dedican
enteramente al escenario a veces se comportan diferente, permitiendo efectos
interesantes. Segundo, algunos colores son mapeados a entradas distintas de
paletas hardware dependiendo de la posición virtual del sol, la cubierta de
nubes y la orientación de la superficie a la que se aplican, permitiendo
simular iluminación directa de la luz del sol. Al contrario del sol virtual,
que es invisible pero cambia su situación, la luna virtual es visible pero
siempre esta en el mismo sitio. Probablemente a causa de esto, la iluminación
directa de la luz de la luna no se simula.
El efecto niebla, cuando esta activado, añade un paso
mas a los dos anteriores, cuando se referencia a la paleta hardware las
entradas son remapeadas otra vez de acuerdo a la distancia del espectador.
Dos de las paletas usadas para elegir
colores son muy simples. La paleta 69h es idéntica a la paleta hardware. Los
valores de los colores que se seleccionan especifican entradas directas de la
paleta, parecido a valores de los píxeles en ficheros de texturas.
La paleta 68h permite definir colores
transparentes usados para dibujar superficies que no deberían ocultar
completamente la escena detrás de estas, como las sombras. Como en la paleta
69h, los valores de los colores son referencias a entradas de la paleta. En
las superficies transparentes, solo el segundo píxel se dibuja en la
pantalla. La mitad de los píxeles de la escena de detrás permanecen
visibles, lo que crea el efecto de transparencia. Por otro lado, una
superficie transparente nunca se verá a través de otra superficie
transparente, ya que exactamente todos sus píxeles serán repintados. Esta
paleta solo se puede usar con superficies, no con líneas. Debido a esto, las
líneas no producen sombras en el MSFS.
El FS5.1 tiene un bug que a veces
provoca que los colores de esta paleta se pinten incorrectamente durante las
horas oscuras cuando la vista del mapa esta activada.
La paleta F0 es la mas compleja y una de
las mas usadas. Al contrario que las otras dos paletas que se usan para
acceder a entradas de paleta, esta se usa para especificar propiedades de las
superficies.
Casi todos los colores de esta paleta
cambian su intensidad dependiendo de la orientación de la superficie y de la
posición del sol virtual. Esto permite una muy buena simulación de la
iluminación de los rayos del sol. Cada uno de estos colores tiene múltiples
entradas de paleta. Luego el color se mapea con la entrada que se ajusta mas a
la intensidad actual. Debido a esto, estos solo son colores que se pueden usar
para polígonos con sombra.
Estos colores quedan ilustrados
perfectamente por los edificios por defecto, que cambian la intensidad de sus
caras durante el día. Por otro lado, la paleta F0 solo se usa cuando las
texturas de edificios están desactivadas - los edificios con textura usan una
forma distinta de generar el mismo efecto.
Otros colores de esta paleta no cambian
su intensidad de esta forma. Muchos de ellos se mapean a entradas de la paleta
que permanecen iluminadas durante la noche y se usan para efectos de noche.
También existe un color blanco especial que cambia su intensidad durante el
día pero permanece iluminado durante la noche.
Esta paleta tiene muchos menos colores
que 256. Mientras que en verdad es posible especificar 256 colores, muchos de
ellos dan como resultado objetos que cambian sus colores de forma aleatoria de
acuerdo con la posición del sol por lo que son inservibles.
Los polígonos con colores sólidos son
útiles para definir superficies planas, pero no se pueden usar para objetos
curvos. La única forma de visualizar objetos curvos en el MSFS es
construirlos desde primitivas, las cuales todas serán planas. Por lo que, los
cambios de color entre polígonos vecinos serán claramente visibles.
Este problema se resuelve usando los
llamados polígonos sombreados. No son pintados con un color sólido, si no
que su color varia su intensidad dentro del polígono. Esto crea una ilusión
muy real de luz reflejada en una superficie curva. Poliedros construidos desde
polígonos sombreados se ven perfectamente redondos, incluso si el ojo coge
sus esquinas. Un buen ejemplo de un objeto de estos es el globo aerostático
que está en Chicago cuando se ve desde cerca.
Además de usar capacidades de paletas
de colores en el MSFS, el escenario puede escoger distintas especificaciones
de color dependiendo de distintos factores, como la hora del día o la
posición del avión. Esto permite crear muchos efectos como luces nocturnas,
luces parpadeantes o sistemas de aproximación visuales, que no se pueden
implementar manipulando colores que ofrecen las paletas estándares por si
solas.
volver al contenido
Como el MSFS dibuja los objetos 3D
Al contrario de los objetos 2-D, que son dibujados en el
mismo orden en que aparecen los comandos de dibujado en los ficheros BGL, los
objetos 3-D se dibujan en un orden que es determinado internamente por el MSFS
y se supone que resuelve los problemas de visibilidad. El código que define
el escenario visual tiene partes (subrutinas) que se usan para visualizar
objetos 3-D. Estas partes no son ejecutadas directamente. En cambio, el MSFS
es notificado de su presencia y después las ordena de acuerdo con la
distancia del observador y las ejecuta en el orden apropiado.
Las subrutinas para visualizar objetos 3-D normalmente
están en el escenario visual. Internamente, el MSFS utiliza subrutinas
parecidas para dibujar el propio avión desde vistas externas, objetos de
escenario dinamico, montañas del escenario sintético y edificios, etc. Esto
normalmente asegura que estos objetos 'cabrán' bien en el escenario visual.
Las únicas primitivas gráficas soportadas por el MSFS
son puntos, líneas y polígonos. Por consiguiente, muchos objetos 3-D se
construyen mediante múltiples primitivas gráficas. Estas primitivas 3-D son
proyectadas en la vista de la ventana, resultando de esta manera en primitivas
2-D que son visualizadas por el driver gráfico. Todo esto nos lleva al
problema de las superficies ocultas (o, generalizando, partes) entre objetos.
Por ejemplo, la cara mas alejada de un edificio no debería verse a través de
la cara mas cercana.
El MSFS solo soporta una primitiva de
eliminación de superficies ocultas entre objetos 3D, que funciona solo con
polígonos. Está basada en el hecho de que casi todos los objetos son, o
están hechos de, poliedros convexos, y el punto de vista normalmente no puede
estar dentro de este poliedro (por otra parte habría una condición de
choque). Cada polígono en el MSFS es visible solo por una cara. Normalmente,
las caras exteriores del poliedro están programadas para ser visibles. Debido
a la naturaleza del poliedro convexo, solo las caras giradas hacia el
espectador son visibles, y estas caras nunca se cubren entre ellas.
Este solo método simple resuelve
perfectamente el problema de las superficies ocultas para muchos objetos
simples, como edificios por defecto o montañas de escenario sintético, está
muy bien ilustrado por el hecho de que desde dentro de un edificio, sus muros
no son visibles. De forma similar, una montaña normalmente no es visible
desde "dentro". Por otro lado pueden verse caras de montañas
adyacentes aguantarse en el aire - debido a que se están viendo desde su cara
visible.
La única forma de visualizar objetos
mas complejos es dibujar sus partes en un orden que asegure que las partes
cubiertas del objeto son repintadas por partes cubiertas. Al contrario que las
relaciones entre objetos 3-D, donde este problema normalmente es resuelto por
el MSFS, el problema entre objetos tiene que ser resuelto por el mismo código
SDL. El SDL tiene instrucciones que son suficientes para resolver la mayoria
de los problemas con superficies ocultas.
Estas instrucciones nos permiten verificar donde se
encuentra el punto de vista de una cara especifica de un plano imaginario. La
idea basica aqui reside en dibujar un plano imaginario que corte el objeto en
dos piezas sencillas en que ambas son lo suficientemente simples para ser
dibujadas sin problemas internos de visibilidad, o se pueden dividir usando el
mismo sistema en varias piezas simples. Obviamente, la parte situada en la
misma cara del plano de vista nunca puede ser cubierta por la pieza del lado
opuesto. Entonces la pieza del lado opuesto se dibuja primero. Teóricamente,
cada configuración 3D se puede renderizar usando este algoritmo. En la
práctica, objetos 3-D muy grandes (como areas montañosas) a menudo causan
problemas por sus limitaciones internas en el MSFS. Aun así, este metodo es
suficiente para visualizar objetos pequeños, como edificios.
Muchos objetos 3-D tienen sombras. Una sombra normalmente
se genera ejecutando una subrutina SDL usada para visualizar un objeto de un
modo especial que causa que sus primitivas se proyecten en el suelo. Dibujar
la sombra requiere el mismo numero de primitivas que si se visualizara como un
objeto. Por lo que, activando las sombras resultará en un impacto
significativo en el ratio de frames.
Así mismo, muchos objetos 3-D soportan
detección de colisión. "Soportan" quiere decir que el código que
los dibuja también intenta determinar si el avión ha colisionado con el
objeto, y cambia un registro si se cumple.
Un algoritmo correcto de
detección de colisión normalmente debería chequear que las coordenadas de
la aeronave están dentro del objeto. Por otro lado, el SDL ofrece una
variedad de comandos muy pobre para chequear las coordenadas de la aeronave.
Sin usar técnicas complicadas y dificultosas de programar, solo es posible
ver si la aeronave está dentro de un arrea en forma de cubo. Esto no es
suficiente para muchos objetos no rectangulares, como montañas. Por este
motivo, las coordenadas del punto de vista se usan a menudo en vez de las
coordenadas de la aeronave. El SDL tiene una lista mas buena de instrucciones
para monitorizar las coordenadas del punto de vista.
La detección de colisiones
basada en el punto de vista, no siempre va bien. Funciona correctamente solo
cuando se usa el punto de vista desde dentro del avión. Por otro lado, no
siempre este es el caso. El punto de vista puede ser la torre, el avión de
seguimiento (spot plane) o un satélite espía (vista del mapa). Si el spot
plane colisiona con un objeto, pude lanzar una falsa detección de colisión.
Para evitar estos casos, la detección de colisión basada en el punto de
vista solo se activa en ventanas que visualizan la vista de cabina. Si no hay
ventanas abiertas, no funciona siempre. Por ejemplo, es posible volar dentro
de muchas montañas con solo la ventana de spot activa. Tan pronto como se
pulse la tecla 'S', sucederá la colisión - asumiendo que la detección
general de colisión está activada.
Después de un cambio de
situación brusco del avión, el avión puede a menudo colisionar con el suelo
a causa del cambio de altitud del avión y lentitud en el ajuste de la altitud
del suelo synth. Estas situaciones pasan a menudo despues de cargar un fichero
de situación, usando el menu World - Airports o desactivando el modo slew -
el avión "salta". Para evitar estas colisiones, el MSFS deshabilita
temporalmente la detección de colisión unos segundos. Después de este
tiempo, la altitud del terreno se ha establecido correctamente y el avión ha
caído en el suelo, si tenia que hacerlo así. Después de este periodo de
tiempo, la detección de colisión se vuelve a habilitar automáticamente.
Por otro lado, la detección de
colisión permanece activada después de seleccionar un nuevo avión. Si es
más grande que el anterior, su tren de aterrizaje a veces está por debajo
del terreno. Entonces el avión "salta" y a menudo colisiona cuando
cae de nuevo al suelo.
volver al contenido
|