Introdução do PlanoBR 2004

O que é o PlanoBR ?

O PlanoBR é um projeto criado pelo FSA em 1993 com o objetivo de concentrar os esforços dos cenaristas brasileiros na meta de construir cenários do nosso país para o Microsoft Flight Simulator. O principal objetivo do projeto era termos cenários fidedígnos com relação aos auxilios navegação e aos relevos, o segundo extremamente limitado pelos recursos do simulador e das ferramentas ainda em desenvolvimento na época.

Pelo menos uma dezena de cenaristas participou dessa fase do projeto, todos com cenários de qualidade, mas dois se destacaram pela dedicação e afinco. Esses dois, sozinhos eram responsáveis por mais de 98% de todos aerodromos: Fernando Cronemberguer e Alcides Barbosa. Essa versão do PlanoBR cobria todo território nacional com centenas de aerodromos e aeroportos por todo país. A última versão do PlanoBR foi a 3.12 para FS-98.

Em agosto de 2004 tomamos ciência de um projeto audacioso de dois integrantes do FSA, José Francisco Lobo (cujas clássicas apostilas se encontram para download em nossa biblioteca) e Oséas Dourado. Na mão desses dois engenheiros do vôo simulado, vimos o relevo do Brasil sair dos bancos de dados da NASA e pousar no simulador de vôo. Fizemos um vôo pelo litoral do Rio de Janeiro (região onde estamos acostumados a voar na vida real) e o resultado era assombroso, tivemos a nítida impressão pela primeira vez num simulador de vôo de realmente estar fazendo um procedimento naquela localidade. O projeto é o mais rico em detalhes já desenvolvido para o Brasil. Imediatamente sentimos que era uma boa oportunidade para o renascimento do PlanoBR e assim sugerimos.

A primeira fase do novo projeto entitulada pelos seus autores de RelevoBR trás o relevo de todo território nacional para dentro do simulador. O PlanoBR não pretende parar aí, queremos disponibilizar também todos os tipos de cenários e addons compativeis com o relevo, reconstruindo assim os aerodromos e aeroportos que o Flight Simulator deixou de fora em nossos estados, todos estão convidados a participar (saiba como em nossa lista de discussão).

A primeira fase, o RelevoBR está concluida. A seguir leia a respeito do projeto e faça download dos arquivos dos estados que desejar voar. Comentários e troca de idéias são sempre muito bem vindo em nossa lista de discussão, o cadastramento é na página principal do site.

Adriano Carvalho
FSA
Rio, 11/11/2003

Autores:
JOSÉ FRANCISCO LÔBO - OSÉAS DOURADO

RELEVO DO TERRITÓRIO BRASILEIRO
PARA VÔO SIMULADO

Nossa Homenagem ao Pai da Aviação, o brasileiro Alberto Santos Dumont, o primeiro a criar um aparelho mais pesado do que o ar, capaz de decolar, manobrar e pousar pelos seus próprios meios.

Os autores agradecem as dicas e sugestões de Lauro Reis, referência em vôo simulado no Ceará.

Logotipo do Projeto SRTM (NASA)




SUMÁRIO

1 INTRODUÇÃO
2 SHUTTLE RADAR TOPOGRAPHY MISSION (SRTM)
3 A TERRA DO SIMULADOR DE VÔO
3.1 Nível de Detalhe (Level of Detail - LOD)
4 ERROS: CAUSAS, CONSEQÜÊNCIAS E SOLUÇÕES
4.1 Causas Conhecidas
4.1.1 A Ressalva da NASA
4.1.2 Compilação dos Arquivos SRTM
4.1.3 Erros do FS2002/FS2004
5 CONSIDERAÇÕES FINAIS
5.1 Opcionais versus Básico
5.2 O papel da Internet
5.3 DOWNLOAD

1 INTRODUÇÃO
Este trabalho tem por objetivo apresentar técnicas e documentações empregadas pelos autores na elaboração dos arquivos de relevo de todo o território nacional, para utilização nos FS2002/FS2004, disponibilizados de forma gratuita e despretensiosa no Fórum de Simulações Aéreas (FSA), por especial deferência do Sr. Adriano Carvalho. Os arquivos foram compilados com a utilização de ferramentas da Microsoft e, principalmente, de pesquisadores independentes, cujos programas gratuitos permitiram a utilização de dados SRTM liberados pela NASA, resultando numa malha de pontos de relevo na resolução de 76,4 m dividida por Estados.

A partir da versão FS7 (Flight Simulator 2000) a Microsoft deu início a importantes modificações relacionadas com os elementos do terreno, possibilitando um detalhamento maior e de melhor qualidade gráfica das características geográficas, sem que isso sobrecarregasse a máquina do usuário, e ampliando a idéia de “cenário” para limites muito além das vizinhanças dos Campos de Pouso.

Com a publicação de documentos técnicos, embora em linguagem árida e de difícil entendimento, os conhecidos Software Development Kits (SDK), em meados de 2000, a Microsoft começou a divulgar alguns detalhes das modificações introduzidas na nova versão do programa, quando alguns pesquisadores já tinham “descoberto” o funcionamento de algumas dessas novidades e apresentado soluções para suas modificações. Pela forma sucinta como são apresentados os SDK e considerando que se trata de assuntos novos e complexos, é lícito dizer que os mesmos não estão ao alcance da maioria das pessoas.

Mesmo sem revelar como fazê-lo, a empresa admitia em seu papel:

“O modelo da Terra empregado no Simulador de Vôo 2000 está previsto para ser inteiramente utilizado, embora não seja incluída uma grande quantidade de detalhes em todos os lugares. Entretanto, onde quer que o usuário possa ir, sempre haverá algum tipo de cenário disponível. Ele poderá definir um maior e melhor detalhamento de uma região específica de maneira relativamente fácil, utilizando programas destinados a esse fim. Poderá acrescentar polígonos texturizados, linhas e pontos para modelar uma região que reflita a realidade que ele escolher” (Scenery in Flight Simulator 2000).

Todavia, para que tais modificações fossem facilitadas, os programadores deveriam ter conhecimento oficial de detalhes das estruturas dos arquivos e de como modificá-los, sem o que não seria possível desenvolver aplicativos. Naturalmente, não se pode culpar a empresa pelo fato de ela preservar seus segredos comerciais, somente divulgando as informações que considerar oportunas para o trabalho dos programadores.

Em maio de 2002, após o lançamento da versão FS8, novos documentos SDK lançaram mais luz sobre essas modificações do terreno. A empresa disponibilizou algumas ferramentas para compilação dos arquivos modificados pelos usuários: resample.exe, tmfcompress.exe, tmfmerge.exe e tmf2bgl.exe. Novamente entraram em ação os mais experientes conhecedores do programa que publicaram seus pontos de vistas sobre o assunto, de maneira mais didática e compreensível por nós, leigos na matéria.

As principais modificações que se podia fazer eram aquelas referentes à transformação de água em terra e vice-versa, favorecendo a criação ou modificação de lagos e ilhas. Tornou-se público que o planeta terrra da microsoft era composto de água e que esta poderia transformar-se em terra firme. Onde já houvesse terra firme poderíamos convertê-la em água. Ou seja, poderiam ser criados ilhas com lagos internos e também lagos em terra firme com ilhas em seu interior, com texturas d’água realmente flutuável.

A partir do FS2002 também passou a ser possível a modificação do relevo, com base em dados mais precisos, principalmente com a utilização de arquivos do tipo Digital Elevation Model (DEM). Alguns cenários já apresentavam esses relevos de melhor precisão, notadamente para a região dos EUA, cuja administração disponibiliza arquivos de relevo para todo o seu território contínuo e, também, para o Alasca e o Havaí.

Havia programas “freeware”, de ótima qualidade, que tornavam a utilização das ferramentas e técnicas de compilação liberadas pela microsoft mais palatáveis para o leitor comum. De posse destas técnicas e ferramentas, passamos a procurar os dados para tornar mais próximo da realidade o relevo de nossa região, que é visivelmente diferente daquele apresentado pelo simulador de vôo, inclusive pela sua versão mais recente: FS9 ou FS2004. Cobrindo o território americano, havia muitos dados disponíveis. Para nossa região, quase nada, à exceção do Projeto GTOPO30, um estudo topográfico digital concluído em 1996. Trata-se de um modelo de elevação digital (DEM) com pontos dispostos numa grade horizontal espaçados de 30 arcos de segundos ou aproximadamente 928 metros.

Tínhamos a idéia e a máquina para fabricar o produto, porém faltava a matéria prima: os dados sobre o relevo do nosso território.

2 SHUTTLE RADAR TOPOGRAPHY MISSION (SRTM)
Os dados do GTOPO30 são utilizados pelo FS2000 e pelo FS2004 para cobrir todo o mundo. Neste caso, não há nada a melhorar nos nossos cenários com a utilização deles, embora alguns pesquisadores digam que podem ser re-amostrados para uma melhor resolução, de 611,5 m, no LOD 6, assunto que abordaremos no capítulo 3.

Sabíamos que estava em andamento um projeto da NASA de levantamento topográfico de toda a Terra, por meio de radar, cuja leitura fora realizada no período de 11 a 22 de fevereiro de 2000. Os arquivos seriam disponibilizados para todas as regiões do mundo, com resolução de um arco de segundo, ou seja, pontos de altitudes conhecidas, dispostos numa grade horizontal, e espaçados de 30,9 m apenas. Surgiram os primeiros dados desse projeto para a região contínua dos EUA. A América do Sul seria a próxima região a ser disponibilizada, prometia a NASA.

Por volta de maio/junho de 2003, localizamos os dados desse projeto, relativamente ao continente Sul-Americano, nos endereços:

http://seamless.usgs.gov/ e no servidor de dados da USGS:

ftp://edcsgs9.cr.usgs.gov/pub/data/srtm/South_America/

Por motivos que não conhecemos, mas supomos que sejam de interesse comercial, a NASA liberou para a América do Sul apenas os dados na resolução de três arcos de segundos, ou seja, uma grade com pontos espaçados de 92,8 m, aproximadamente. Pelas características dos LOD’s, é possível re-amostrar esses pontos para o intervalo de 76,4 m, como mostraremos neste trabalho. No estado da arte, consideramos esta resolução ideal para o vôo simulado, pelos seguintes aspectos:

a) Excetuando os picos muito agudos, as regiões montanhosas apresentam-se, em geral, bem delineadas, realçando o terreno, principalmente quando este exibe uma Cobertura do Solo que harmoniza com a região (Landclass);

b) Os tamanhos dos arquivos compilados (formato .BGL), apesar de grandes, estão dentro de limites aceitáveis. Podemos ter arquivos de todo o território brasileiro no espaço de dois CD’s, ou cerca de 1.2 GB. Vale a pena salientar que faz pouca diferença se o arquivo BGL é pequeno ou grande, porquanto o simulador de vôo carrega na memória apenas a região do cenário visível, gradualmente, à medida que o vôo se desenvolve;

c) Uma máquina de capacidade média, em termos de memória, processador e placa de vídeo, não sofrerá grande queda no número de quadros por segundo (frame rate). Contudo, este parâmetro é configurável pelo usuário, levando em conta a capacidade de sua máquina. Na Seção 4.2 mostramos como fazer esta configuração nos FS2002/FS2004.

Figura 1 - Área Coberta por um Arquivo SRTM

Cada arquivo SRTM na resolução de 3 arcos de segundo tem o tamanho aproximado de 1,2 MB compactado, dependendo do relevo do local. Através do seu nome identificamos a latitude e longitude da região coberta. Por exemplo: o arquivo S04W039.hgt cobre uma região entre os Paralelos 03º e 04º graus Sul e entre os Meridianos 039º e 038º Oeste. Seu nome identifica o canto inferior esquerdo da região coberta. O quadrado formado, de 1 x 1 grau, corresponde a uma área de cerca de 111 x 111 quilômetros.

Figura 2 - Relevo da América do Sul

Entretanto, o formato quadrado somente ocorre sobre a Linha do Equador ou em suas proximidades, onde os círculos latitudinal e longitudinal têm valores aproximados. À medida que os pontos se afastam desta linha imaginária, em direção aos pólos, os comprimentos dos meridianos não variam, enquanto que os paralelos correspondem a círculos cada vez menores, até chegar a um simples ponto, nos pólos Norte e Sul da Terra. Isto significa que as distâncias devem ser medidas sempre na direção da latitude, ou seja, sobre um meridiano, cuja linha tem o comprimento constante.

Fonte: Site da NASA

Todos os arquivos SRTM que cobrem o continente sul-americano ocupam o espaço equivalente a quatro CD’s. Após ser expandido, o arquivo adquire a extensão .hgt. Seu conteúdo, ou seja, o relevo formado pelos seus pontos, pode ser visualizado tridimensionalmente, em quadrados de 1 x 1 grau ou composto em um mosaico formado por vários arquivos contíguos ou não. Essa visualização pode ser útil para comparar com o relevo visto no simulador de vôo e assim tirar alguma dúvida com relação a eventuais erros.

Figura 3 - Visualização do arquivo S04W039.hgt, com o programa 3DEM

3 A TERRA DO SIMULADOR DE VÔO

Aprendemos nas primeiras aulas de Geografia que “a Terra tem o formato aproximado de uma esfera, achatada nos Pólos e dilatada no Equador”. Para mapeamento desse sólido de formato especial, os cartógrafos definiram modelos matemáticos chamados de Data File Datum. Um desses modelos, o WGS84, é utilizado na maioria das cartas de navegação marítima e aérea, em suas variadas projeções. Este modelo é também utilizado pelos programas de simulação de vôo e tem as seguintes características físicas:

Diâmetro Equatorial 12.756,27 km

Circunferência Equatorial 40.075,00 km

Diâmetro Polar 12.734,62 km

Circunferência Polar 40.007,00 km

O arco de um grau de latitude 111.320,70 m

O arco de um minuto de latitude 1.855,345 m

O arco de um segundo de latitude 30,92241667 m

3.1 Nível de Detalhe (Level of Detail - LOD)

Dentre as modificações introduzidas pela microsoft, a mais importante foi a criação de uma escala de tamanhos de áreas que ela denominou de LOD’s. Nesta escala, a menor dimensão que pode ser definida no cenário é denominada de Ponto e corresponde a uma superfície de 4,78 x 4,78 m, aproximadamente. Assim, podemos dizer que o cenário tem uma resolução ou um nível de detalhe de 4,78 m, porque esta é a menor dimensão que pode ser definida. Qualquer objeto menor não será representado corretamente. Provavelmente, em futuro próximo, com máquinas mais potentes, esse valor cairá progressivamente para 2,40 m e 1,20 m, permitindo detalhar melhor os elementos do terreno, como: rios, ruas, estradas e outros objetos de pequenas dimensões representados sobre as texturas.

Por sua vez, os pontos são agrupados em pequenos quadrados, numa malha de 256 x 256, totalizando 65.536 pontos. O lado do quadrado formado por esses pontos mede 256 x 4,78 = 1.223 m. Estes quadrados serão chamados de Áreas neste texto. A cada área corresponde uma textura no formato “bitmap” de 256 x 256 pixels. Portanto, cada ponto de 4,78 m corresponde a um bit mapeado ou endereçável da textura.

Figura 4 – Divisão da Terra em LOD’s

Para chegar aos tamanhos da área e do ponto, a microsoft partiu das dimensões reais da Terra, apresentadas acima, dividindo sucessivamente por dois, nas direções norte/sul e leste/oeste, como pode ser observado na figura 4 e na tabela I, na página seguinte.

Na figura acima, vemos o cruzamento do Meridiano de Greenwich com a Linha do Equador, que marca o início da contagem das coordenadas geográficas e dividem a Terra em quatro quadrantes. Entretanto, a numeração dos LOD’s inicia-se no canto superior esquerdo do mapa e aumenta para a direita e para baixo. Por isso, as coordenadas geográficas que identificam um LOD são aquelas do canto superior direito (N/W). Cálculos simples permitem identificar o número do LOD a partir de suas coordenadas e vice-versa.

A coluna Sample Size Meters especifica os valores que serão adotados pelo programa de compilação Resample.exe para re-amostrar os dados de elevação, durante a compilação dos arquivos .BGL de relevo. O parâmetro repassado é o número do LOD respectivo, através de um arquivo de dados .INF que o compilador lê e interpreta.

Embora os pontos do arquivo SRTM de 3 arcos de segundos sejam espaçados de 92,8 m, eles são re-amostrados, quer dizer, são gerados pontos intermediários, necessários para criação de uma nova malha com o espaçamento padronizado de 76,4 m, correspondente ao LOD 9. Os novos pontos são gerados através de algoritmos complexos, levando em conta os pontos adjacentes.

Tabela I - Nível de Detalhes (Level of Detail - LOD)

Fonte: Creating Terrain in Flight Simulator 2000

Com efeito, o simulador de vôo não exibe esses pontos e sim pequenos triângulos formados por eles, unidos uns aos outros. O resultado é uma superfície suavemente renderizada, sem arestas vivas, modelando de baixo para cima a textura aplicada no local e representando com razoável precisão as formações do terreno.

Os arquivos SRTM de 1 arco de segundo são re-amostrados para o LOD 10 (38,2 m), ou seja, o dobro da resolução obtida com 3 arcos de segundo. Entretanto, o tamanho do arquivo BGL é cerca de 12 vezes maior, não justificando o ganho relativo ao SRTM de 3 arcos de segundo. Esta é a quarta razão, além das apresentadas na página 6, para considerarmos a resolução de 76,4 m ideal para o estado da arte.

Quanto aos arquivos SRTM de 3 arcos de segundo, ao compararmos com a resolução obtida com os dados do projeto GTOPO30, re-amostrados para o LOD 5 no espaçamento de 1.223 m, observamos um ganho excelente em qualidade, sem sacrificar o desempenho de uma máquina de capacidade média. Estamos substituindo uma malha de 4 pontos por outra com 256 pontos de alturas conhecidas ou bem estimadas, dentro do mesmo espaço de 1.223 x 1.223 m!

As colunas da Tabela I “Lat Deg Boundries” e “Lon Deg Boundries” indicam quantos graus de amplitude cada LOD mede tanto na direção vertical (Y ou latitude) quanto na direção horizontal (X ou longitude). Na coluna “Spam Meters” estão indicadas as medidas laterais de cada uma dessas superfícies retangulares, feitas na direção vertical Y ou da latitude, pois, conforme foi citado na página 7, a medição só é correta se for feita ao longo de um meridiano.

Os LOD’s apresentam um valor em graus na direção X (longitude) maior do que na direção Y (latitude) (fator de 120/90 = 1,3333), formando superfícies retangulares e não quadradas. Entretanto, cada LOD 13 ou Área é representado por uma textura quadrada de 256 x 256 pixels. Um LOD 8, também conhecido como Célula, é formado por 32 x 32 LOD’s 13. A Terra toda está dividida em 512 LOD’s 8, na direção X (longitude), e por 768 LOD’s 8, na direção Y (longitude). Lembramos que a menor superfície que pode ser modificada é o LOD 13, correspondente a uma textura.

Somente os LOD 13, 8 e 5, este último formado por 64 x 64 LOD 8, são utilizados para modificações embora, na realidade, estas sejam feitas nas áreas (LOD 13).

Considerando as definições dos LOD’s dadas na Tabela I, podemos determinar as coordenadas de seus cantos, o que os torna completamente identificáveis. Sem dúvida, trata-se de um sistema de coordenadas criado especialmente para o simulador de vôo, que trabalha com superfícies, sendo a menor delas de 4,78 x 4,78 m, embora chamada de ponto. Como podemos visualizar na Tabela I, os futuros LOD 14 e LOD 15 já estão definidos.

É importante observar que o conceito de LOD é usado em duas acepções: uma no sentido de resolução dos elementos do terreno e outra no sentido de localização geográfica, muitas vezes confundindo o leitor.

4 ERROS: CAUSAS, CONSEQÜÊNCIAS E SOLUÇÕES

4.1 Causas Conhecidas

Os arquivos de relevos envolvem entidades oficiais, programas de computador, autores e leitores, desde a aquisição de dados até a sua utilização no Simulador de Vôo, podendo haver erros, enganos ou omissões em quaisquer destas partes, por qualquer um dos envolvidos no processo. Algumas causas de erros podem ser identificadas e, portanto, corrigidas. Para estas, apresentamos as soluções conhecidas.

4.1.1 A Ressalva da NASA

A NASA adverte aos usuários dos seus dados topográficos digitais que se trata de “uma versão ainda não editada, destinada ao uso científico e para avaliação”. Ressalva ainda: “existem numerosos espaços vazios entre eles, sobretudo nas regiões cobertas por água, cujas superfícies podem aparecer desniveladas, assim como as linhas costeiras, que podem não figurar corretamente”. Por conseguinte, esta é a primeira causa de erros, principalmente nas superfícies d’água, onde o eco do radar é impreciso. A principal vantagem da obtenção desses dados por um par de radares de interferometria é que a operação independe da iluminação do Sol e da cobertura de nuvens sobre a Terra.

Recomendamos leituras adicionais sobre o projeto SRTM, disponíveis nos sites http://www.nasa.gov/ e http://photojournal.jpl.nasa.gov/PIA.html.

4.1.2 Compilação dos Arquivos SRTM

Antes de serem re-amostrados para a resolução de 76,4 m e compilados em um arquivo .BGL utilizável pelo simulador, os dados dos arquivos SRTM devem ser corrigidos e também o formato do arquivo modificado para um tipo compilável pelo programa Resample.exe, da Microsoft. Temos conhecimento de dois programas freewares que fazem este trabalho: FSTERRAIN 2002 e o SRTM_3ARCSEC_TO_BGL.

Este último é de uma utilização tão fácil que, até certo ponto, banalizou a compilação de arquivos de relevo a partir de dados SRTM.

Entretanto, o programa compila os dados que lhe são repassados e ao formatar uma determinada área pode haver engano na seleção dos arquivos SRTM, resultando em lacunas dentro da área, por falta de um ou mais arquivos de dados. Se houver uma montanha cortada abruptamente, formando um paredão, isto pode ser causado por falta de dados. Se for observada qualquer ocorrência desse tipo, os autores solicitam que lhes seja comunicado através de e-mail.

Figura 5 - Malha de 1 x 1 grau, cobrindo o território brasileiro

Fonte: Internet – Mapa configurado com auxílio do programa OziExplorer.

A figura 5 dá uma idéia da malha que cobre o território brasileiro e da atenção necessária para a seleção dos arquivos corretos para cada Estado. Sem sombra de dúvida, esse é o principal diferencial da nossa compilação, comparada com inúmeras outras que temos visto na Internet, inclusive para o Brasil.

Para a visualização contínua do relevo torna-se necessário que os BGL contíguos sejam instalados e ativados. Verifique no mapa da Figura 5 quais são os Estados vizinhos ao que você vai sobrevoar e forme uma grande área, com este Estado no Centro e os vizinhos nas laterais. Isto é necessário porque os relevos de alguns Estados precisam ser complementados com os relevos dos Estados vizinhos, tal como acontece com: AL-SE, CE-RN, ES-RJ, etc.

Quem tem espaço disponível no HD poderá baixar, instalar e ativar todos os Estados. Conforme já foi dito anteriormente, o simulador somente carregará na memória a área visualizada, não sobrecarregando o desempenho em termos de quadros por segundo (frame rate). Essa simples medida evitará que o leitor, voando próximo aos limites de um Estado, quando os dados desse relevo terminam, observe uma descontinuidade. Se o BGL relativo ao relevo do Estado vizinho estiver instalado e ativado isso não ocorrerá. O simulador de vôo carregará os dados à medida que forem necessários, eliminando a falha antes que ela seja visualizada.

4.1.3 Erros do FS2002/FS2004

Os reservatórios d’água, em alguns casos, aparecem com suas margens acima do terreno. Também é possível que algumas pistas de pouso apresentem-se mais altas ou mais baixas do que o nível do solo, no novo relevo. O principal motivo destas diferenças deve-se ao fato de lagos e pistas serem formados por polígonos, com alturas pré-definidas.

No caso das pistas de pouso, cujas altitudes geralmente são conhecidas, os polígonos de nivelação (flat) não apresentarão grandes diferenças em relação ao nosso relevo. Quanto aos lagos, formados por polígonos LWM, e referidos a altitudes obtidas diretamente do relevo anterior (GTOPO30), as discrepâncias geralmente são maiores.

Num próximo trabalho mostraremos como o próprio leitor poderá corrigir estes desnivelamentos, utilizando programas e mapas geo-referenciados, disponíveis na Internet, e bem como as dicas para modificação das coberturas do solo. A Microsoft ainda não publicou documentos sobre as novas coberturas do solo e elementos disponíveis para modificação do terreno no FS2004, que estão mais variados e bonitos do que nas versões anteriores.

5 CONSIDERAÇÕES FINAIS

5.1 Opcionais versus Básico

Quantas vezes fizemos esta pergunta: “Por que esta função ainda não é básica no simulador de vôo?”.

Parece estar claro que o simulador de vôo é uma versão geral que atende apenas uma parte dos seus usuários, deixando aos demais a opção de modificar ou adicionar um sem número de utilitários, como: cenários, aeronaves, painéis, sons, módulos e outros aplicativos, que venham ao encontro de suas necessidades de lazer ou de treinamento. Ainda que de forma velada, a Microsoft incentiva esse comércio paralelo porque esta é uma forma de divulgar o seu produto num meio especializado, e a venda destes acessórios parece não lhe interessar.

Um destes opcionais é o relevo do terreno. No caso brasileiro isto seria justificável pela falta de dados. Entretanto, mesmo dentro do território dos EUA, onde os dados para a sua compilação são encontrados com facilidade, não existem arquivos de relevo cobrindo todo o território. Uma outra razão plausível é que isto resultaria num grande número de CD’s, muitos dos quais seriam mesmo rotulados de opcionais e, certamente, frustraria seus clientes por pagarem por estes excessos.

De um modo geral, o relevo quase não baixa o número de quadros por segundo que você obtém antes de instalá-lo; se você observar uma queda significativa, provavelmente é causada por outros add ons instalados.

Felizmente, já dispomos do nosso próprio relevo, em resolução muito boa, baseado em dados de topografia digital originados de fonte confiável e, o que é mais importante, de graça, como convém. Não estamos reivindicando qualquer mérito por conta disso. Mais cedo ou mais tarde alguém tomaria essa iniciativa.

Sem exagero, o relevo brasileiro marcará o início de uma fase inteiramente nova para o vôo simulado em nossas plagas!

5.2 O papel da Internet

Computadores dotados de processadores e memórias maiores e mais rápidos, melhores placas de vídeo, etc., tudo isto tem a sua importância para o desenvolvimento do vôo simulado, mas é a Internet, sem sombra de dúvida a mola propulsora do seu crescimento.

A facilidade e rapidez da troca de informações, a disponibilidade de grandes volumes de dados em servidores como o do FSA, os grupos de discussão, que permitem desenvolver amizades com pessoas que nunca vimos ou sequer falamos ao telefone, que estão sempre prontas a falar de suas experiências ou de apreender as experiências dos outros, somente são possíveis através dessa rede de comunicações, coisa inimaginável até há bem pouco tempo. Os mais velhos sabem disso.