Программные продукты и системы

Для воссоздания ощущений реального мира при проведении тренировочных занятий необходимо воспроизвести все сигналы, получаемые оператором во время выполнения операций. Если точно воспроизвести сигналы невозможно, используются их упрощенные модели. Для ряда тренажеров некоторые группы сигналов могут не воспроизводиться из-за невостребованности в данной тренировке, что приведет к снижению сложности тренажера и его удешевлению. Сигналы от тренажера должны быть согласованными, так как мозг человека для получения полной картины происходящего совмещает сигналы, получаемые различными органами чувств [1].

В гражданской авиации наличие функционала моделирования аэропортов и земной поверхности согласно руководству ICAO Doc 9625, vol. I, 2009 является одним из требований к тренажерным системам [2, 3]. Детализация воспроизведения окружающей обстановки напрямую связана с производительностью тренажера. Для повышения эффективности использования ресурсов тренажера необходимо определить, какие группы объектов наиболее важны для достижения целей тренировки, и, следовательно, детально воспроизводить именно эти группы.

С развитием систем дистанционного зондирования Земли, а также систем обработки полученных данных визуализация земной поверхности возможна с использованием спутниковых снимков. Например, со спутника GeoEye-1 можно полу- чать снимки с разрешением 0,5 метра на пиксель. В целях оптимизации производительности снимки хранятся в виде тайлов – небольших изображений одинакового размера, которые являются фрагментами большого изображения.

Необходимо отметить, что на снимках будут видны объекты, находящиеся на поверхности Земли: деревья, дома, тени от домов, самолеты и другие. Для некоторых участков необходима очистка изображений от подобных объектов, такая работа, как правило, выполняется вручную и весьма трудоемка.

Спутниковые снимки должны иметь пространственную привязку – набор параметров, опреде- ляющих систему координат и другие пространственные свойства данных. Данные изображения и пространственная привязка могут храниться в различных форматах – в виде GeoTIFF-файлов, в виде jpg-файла и файла с данными привязки dat и пр. Возможно преобразование формата хранения спутниковых данных, такое преобразование необходимо и в случае, когда на вход подсистемы построения виртуальной земной поверхности необходимо подать файлы в формате GeoTIFF.

Для выполнения преобразований можно воспользоваться утилитой gdal_translate. Зная коор- динаты краев изображения 1_1-1.jpg, которые хранятся в dat-файле, можно получить GeoTIFF-файл: gdal_translate.exe -of GTiff -a_srs "+proj= latlong +ellps=WGS84 +datum=WGS84" -a_ullr 55.4097175598145 51.8169457013069 55.4151141643524 51.8135349076488 1_1-1.jpg A1_1-1.tif. Полученный GeoTIFF-файл будет содержать изображение, а также привязку с параметрами: геодезическая система координат, эллипсоид WGS84, датум WGS84.

Геоид – фигура Земли, ограниченная поверхностью, отвесные линии к которой всюду перпендикулярны и которая проходит через точку начала отсчета высот, закрепленную на высоте среднего уровня моря (рис. 1). Эта поверхность близка к уровням морей и океанов в состоянии покоя и равновесия [4].

WGS84 – Всемирная геодезическая система координат. Поверхность, которой аппроксимируют фигуру всей Земли (геоида), – геоцентрический (глобальный) эллипсоид вращения WGS84 [5].

Для более точной аппроксимации на некотором участке земной поверхности используются референц-эллипсоиды, например, территории отдельной страны или нескольких стран. В России используются эллипсоид Красовского и Система геодезических координат СК-95. Геодезические даты, датум (Datum) – линейные и угловые смещения референц-эллипсоидов относительно центра масс Земли [6].

Для формирования рельефа подстилающей поверхности возможно использование данных, полученных с помощью радарной топографической съемки Shuttle radar topographic mission (SRTM). Для Евразии разрешение данных – 90 метров [7]. Нет SRTM-данных для самых северных (>60) и самых южных (>54) широт.

Проведено сравнение данных SRTM версии 3 с данными аэромагнитной съемки со среднеквадратической погрешностью 0,92 м. Максимальные расхождения между данными достигают по высоте 30 м, причем имеют разный знак. Расхождения обнаружены в основном в областях с переменным рельефом (долины рек), что можно объяснить неточным определением плановых координат точек в методе SRTM [8].

Также необходимо отметить, что при наличии растительности и строений данные высоты измеряются с учетом этих объектов. Следовательно, при проектировании зон повышенного интереса, например аэродромов, необходимо получить дополнительные топографические данные.

Данные SRTM могут быть получены в формате GeoTIFF. Данные являются 16-битным растром (65 536 значений, без заголовка), а значение пикселя – высотой над уровнем моря в данной точке, оно также может принимать значение –32 768, что означает «нет данных» для некоторых участков. Горизонтальный датум – WGS84. Для вычисления высот используется модель геоида EGM96 (Earth Gravitational Model 1996) [9].

При моделировании ландшафта с использованием данных SRTM возможно некорректное отображение местности. Например, прибрежный обрыв может быть смоделирован как пологий берег. Такое возможно, например, в случае недостаточного разрешения исходных данных, что приводит к интерполяции данных.

Полученные исходные данные необходимо оптимизировать для их отображения в системе визуализации. Данные спутниковых снимков для их визуализации должны быть помещены в память видеокарты. Для протяженных участков земной поверхности объем требуемой памяти значителен. Также требуются значительные вычислительные мощности для обработки данных. Имеются ограничения на максимальное разрешение текстуры. Например, изображение участка в 18 км2 имеет разрешение 60 000´30 000 пикселей.

Решением может быть разбиение одного большого изображения на несколько изображений – тайлов, например размером 256´256 пикселей, которые можно быстро обработать. В случае отображения протяженных участков возрастает удаленность наблюдателя от поверхности с текстурой, следовательно, нет необходимости использовать исходные данные самого высокого разрешения. Можно сформировать несколько вариантов снимков одного и того же участка земной поверхности с различным разрешением для каждого диапазона удаления наблюдателя от виртуальной поверхности Земли. Указанные методы применяются в форматах хранения геодезических данных, таких как Tile Map Service (TMS). Подобные преобразования можно проводить одновременно с визуализацией в случае, если производительность не является одной из основных характеристик. В тренажерных системах такой подход неприемлем ввиду огра- ничений на время генерации одного кадра – мак- симум 40 мс. Следовательно, необходимо под- готовить данные заранее. Все вышеизложенное относится и к данным рельефа подстилающей поверхности в случае их хранения в растровом формате типа GeoTIFF.

Для создания TMS-хранилища из исходных данных возможно использование утилиты os­gearth_package. Пример использования: osgearth_ package config.earth --tms --max-level 19 --out d:\tms\. Параметр --max-level необходимо устанавливать в зависимости от разрешения исходных данных. При недостаточном разрешении исходных данных будет произведена экстраполяция данных изображения, что не приведет к улучшению качества итогового изображения.

Пример скрипта для генерации TMS-хранили­ща:

Для хранения информации об объектах на поверхности Земли (аэродромах, самолетах) можно использовать файл формата KML (Keyhole Markup Language) на основе XML. Спецификация KML подразумевает, что сами модели хранятся в файлах формата Collada. Целесообразно преобразовать все модели в бинарный формат для сокращения времени загрузки сцены. При преобразовании моделей в формат Collada возможно появление графических артефактов, например черных тонких линий, разделяющих составные элементы модели. Учитывая, что число моделей может быть большим, потребуется автоматическое преобразование данных.

На одном участке поверхности могут располагаться несколько однотипных объектов, отличаю- щихся только расположением. При загрузке каждого объекта по отдельности создается новый элемент сцены, имеющий свои данные о геометрии и текстуре. Первая проблема связана с заполнением памяти видеокарты несколькими копиями одинаковых текстур. Решением может быть использование ссылки на уже загруженную текстуру в памяти. Для реализации необходимо пройти по узлам графа сцены с целью найти узел с данной моделью.

Вторая проблема – дублирование данных о геометрии объектов.

Данные о сцене можно хранить в структуре, называемой графом сцены. Граф сцены – это иерархическая древовидная структура данных, которая организует данные в пространстве для эффективного отображения [10]. Узлы могут быть нескольких типов (рис. 2).

Узел типа Geode (Geometry Node) (рис. 3) предназначен для хранения объектов Drawables [11]. Drawables не являются узлами сцены, они присоединяются к узлам Geode, позволяют использовать в сцене данные об отображаемых объектах. Объект Geometry является одним из типов отображаемых объектов, хранит массивы вершин, текстурные координаты, данные о цвете и массивы нормалей.

Узел типа Group содержит информацию о дочерних узлах. Узел Transform предназначен для трансформации дочерних узлов, например, для изменения положения объекта при помощи матриц преобразования MatrixTransform (рис. 4) [11].

Пример загрузки 2 000 одинаковых моделей в сцену приведен на рисунке (http://www.swsys.ru/ uploaded/image/2015-4-dop/11.jpg). Создаются узел типа Group и 2 000 дочерних узлов Transform с объ- ектами MatrixTransform. Загружается модель: 34 узла Geode, 34 элемента Geometry. Каждый узел Transform использует копии моделей, следовательно, копии узлов Geode, объектов Geometry и объектов Drawables. В сцене хранится 68 000 Geode, 68 000 Geometry, 68 000 Drawables.

Одной из причин низкой производительности является то, что каждый объект Drawable создает свой Display List – поименованное множество команд OpenGL. Обработка одного Display List занимает фиксированное время вне зависимости от объема выполняемой работы. С уменьшением числа Geometry уменьшается и число Drawables. Уменьшение числа Geometry возможно за счет объединения Geometry. Аналогичные проблемы с производительностью имеются при использовании vertex buffer object OpenGL. В методе предусмотрено создание буферов для вершин и массива атрибутов вершин каждого Geometry. Объединение Geometry возможно, если все объединяемые Geometry используют одинаковую текстуру (см. http://www. swsys.ru/uploaded/image/2015-4-dop/12.jpg) [12].

Алгоритм выполняет последовательный обход всех узлов модели для клонирования и, используя данные, собирает новую модель, содержащую необходимое количество экземпляров исходной модели. Массив вершин (VertexArray) исходной модели изменяется с целью помещения экземпляра модели в необходимое пространственное положение. Массивы нормалей (NormalArray) и текстур- ных координат (TexCoordArray) копируются без изменений. Однако возможны ситуации, при которых число вершин в модели больше числа текстурных координат. В случае объединения Geometry на место недостающих текстурных координат будут записаны значения из следующего экземпляра модели, что приведет к неправильному наложению текстуры. Во избежание подобной ситуации в недостающие текстурные координаты записывается значение (0,0).

Объект PrimitiveSet предоставляет высокоуровневую поддержку команд OpenGL для отрисовки массива вершин. Он используется для определения типов примитивов, которые будут отрисовываться на основании данных, хранимых в Geometry (см. http://www.swsys.ru/uploaded/image/2015-4-dop/13.jpg).

Из PrimitiveSet копируются данные об индексах. Для экземпляров модели к текущему значению индекса прибавляется наибольшее значение индекса у предыдущего экземпляра. Дочерний класс от PrimitiveSet DrawElementsUInt (рис. 5) инкапсулирует OpenGL функцию glDrawElements().

В заключение отметим, что использование методов визуализации и аппаратных платформ позво- ляет создавать высокореалистичное отображение земной поверхности в тренажерно-обучающих системах. Хранение исходных данных блоками в формате Tile Map Service позволило отображать подстилающую поверхность реальных протяженных ландшафтов с приемлемой производительностью. В работе рассматривалась виртуальная сцена с 2 000 однотипных трехмерных моделей. Всего в сцене содержится 6 млн вершин, частота обновления порядка 12 кадров в секунду. После внедрения разработанного метода частота кадров выросла до 83, ранее частота кадров не отвечала требованиям к ТОС: минимально – 25 кадров в секунду.

Необходимо отметить, что при аэрофотосъемке будут видны объекты, находящиеся на поверхности Земли: деревья, дома, самолеты и другие, а также тени от них. Для некоторых участков будет необходима очистка изображений от подобных объектов. Данная работа, как правило, выполняется вручную и весьма трудоемка.

Литература

1.     Allerton D. Principles of flight simulation. Chichester, UK, Wiley, 2009, 471 p.

2.     Решетников В.Н. Космические телекоммуникации. Тригонометрические воспоминания. СПб: Изд-во РИП СПБ, 2015. 138 с.

3.     Гиацинтов А.М. Отображение разнородных видеоматериалов на гранях трехмерных объектов в подсистеме визуализации тренажерных обучающих систем // Программные продукты и системы. 2012. № 3. С. 80–86.

4.     Геоинформационный портал ГИС-Ассоциации – Геоид. URL: http://www.gisa.ru/13065.html (дата обращения: 28.04.2015).

5.     Решетников В.Н. Космические телекоммуникации (начала). М.: Изд-во МАТИ, 2013. 184 с.

6.     Системы координат и проекции. URL: http://www.gis­craft.ru/info/cs/cs.shtml (дата обращения: 28.04.2015).

7.     GIS-Lab: Описание и получение данных SRTM. URL: http://gis-lab.info/qa/srtm.html (дата обращения: 28.04.2015).

8.     Высотные данные SRTM против топографической съемки: все о геологии (geo.web.ru). URL: http://geo.web.ru/db/ msg.html?mid=1177761 (дата обращения: 28.04.2015).

9.     GIAR-CSI SRTM 90m DEM Digital Elevation Database. URL: http://srtm.csi.cgiar.org/SRTMdataProcessingMethodology. asp (дата обращения: 28.04.2015).

10.  Martz P. OpenSceneGraph Quick Start Guide. California: Computer Graphics Systems Development Corp., 2007, 122 p.

11.  OpenSceneGraph: Class List. URL: http://trac.openscene- graph.org/documentation/OpenSceneGraphReferenceDocs/annota- ted.html (дата обращения: 28.04.2015).

12.  Wang R., Qian X. OpenSceneGraph 3 cookbook. Birming­ham, UK, Packt Pub., 2012, 427 p.