Make your own free website on Tripod.com

FS FACTS
Principal ] Página Superior ] Sugerencias ] Links ] Contenido del Web ] Buscar en mi Web ]


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