Embed Size (px)
Citation preview
Федеральное государственное образовательное учреждение высшего
профессионального образования «Нижегородский государственный
архитектурно-строительный университет»
На правах рукописи
Бобков Александр Евгеньевич
Интерактивная визуализация 3D-данных на
виртуальном глобусе в стереоскопических
системах
Специальность 05.01.01 – «Инженерная геометрия и компьютерная графика»
ДИССЕРТАЦИЯ
на соискание учёной степени
кандидата технических наук
Научный руководитель:
доктор физико-математических наук
Афанасьев Валерий Олегович
Нижний Новгород — 2013
2
СОДЕРЖАНИЕ
ВВЕДЕНИЕ ..................................................................................................................... 4
ГЛАВА 1. Методы построения и визуализации виртуальных глобусов ...... 9
1.1. Прошлое и настоящее виртуальных глобусов .................................................. 9
1.2. Обзор программных решений и открытых стандартов .................................. 21
1.3. Генерация рельефа для виртуальных глобусов ............................................... 26
1.4. Выводы по 1 главе .............................................................................................. 37
ГЛАВА 2. Визуализация виртуального глобуса .............................................. 39
2.1. Варианты отображения виртуального глобуса ............................................... 39
2.2. Полупрозрачная поверхность глобуса ............................................................. 46
2.3. Применимость для подземных объектов ......................................................... 58
2.4. Выводы по 2 главе .............................................................................................. 60
ГЛАВА 3. Визуализация данных на виртуальном глобусе ........................... 61
3.1. Облака точек ....................................................................................................... 61
3.2. Объемные данные .............................................................................................. 75
3.3. Выводы по 3 главе .............................................................................................. 82
ГЛАВА 4. Описание программного комплекса ............................................... 84
4.1. Программный комплекс .................................................................................... 85
4.2. Стереоскопическая визуализация ..................................................................... 90
4.3. Навигация и взаимодействие ............................................................................ 96
4.4. Выводы по 4 главе ............................................................................................ 114
ЗАКЛЮЧЕНИЕ ......................................................................................................... 115
БЛАГОДАРНОСТИ .................................................................................................. 117
СЛОВАРЬ ТЕРМИНОВ ........................................................................................... 118
СПИСОК ЛИТЕРАТУРЫ ....................................................................................... 119
3
ПРИЛОЖЕНИЕ А. Источники геоданных ....................................................... 131
ПРИЛОЖЕНИЕ Б. Шейдеры для объемной визуализации .......................... 134
ПРИЛОЖЕНИЕ В. Расчет стереоэффекта ........................................................ 137
ПРИЛОЖЕНИЕ Г. Аппаратное обеспечение ................................................... 143
4
ВВЕДЕНИЕ
Общая характеристика работы
Развитие виртуальных глобусов началось около 10 лет назад. Под
виртуальным глобусом понимается трехмерная модель планеты Земля,
воссозданная с определенной точностью по спутниковым данным, с
интерактивным программным обеспечением, которое позволяет работать с
трехмерной моделью Земли, рассматривать её на любых масштабах и
визуализировать данные (объекты, модели) с привязкой к географическим
координатам. Первые глобусы позволяли просматривать
высокодетализированные спутниковые снимки, наложенные на трехмерный
рельеф. Последние годы растет интерес к использованию виртуальных глобусов
для более практических задач визуализации и анализа различных типов данных на
глобусе. Во-первых, появились спутниковые данные высокого разрешения,
цифровая модель рельефа почти всей Земли в свободном доступе (SRTM). Во-
вторых, широкое распространение получил интернет, что позволило хранить
большие объемы спутниковых данных на удаленных серверах. Видеокарты
позволили интерактивно отображать трехмерный рельеф,
высокодетализированную спутниковую подложку и дополнительные эффекты
вроде атмосферного рассеяния. Основные области применения:
геоинформационные системы (ГИС), системы автоматизированного
проектирования и исследования процессов, компьютерные игры и т.п.
Таким образом, в настоящее время виртуальный глобус является мощным
инструментом для специалистов разных областей, которым требуется
визуализация данных в географическом контексте. Виртуальный глобус может
стать единой платформой для визуализации всех типов данных с географической
привязкой. Для этого необходимо разрабатывать методы визуализации указанных
данных, методы взаимодействия и управления данными в трехмерном
пространстве.
5
В отечественной науке существенный вклад в развитие теоретических основ
и практических решений в области геометрического моделирования и
визуализации внесен научными школами Бондарева А.Е., Васина Ю.Г.,
Галактионова В.А., Дебелова В.А., Денискина Ю.И., Долговесова Б.С., Желтова
С.Ю., Журкина И.Г., Кеткова Ю.Л., Кучуганова В.Н., Никитина И.Н., Роткова
С.И., Сурина А.И., Толока А.В., Турлапова В.Е., Утробина В.А. и ряда других
исследователей.
Актуальность работы обусловлена тем, что, не смотря на существование в
настоящее время большого количество реализаций различных алгоритмов
генерации и визуализации виртуального глобуса (включая атмосферу),
визуализации 3D-данных на глобусе (3D-модели, векторные наложения на
рельеф) и др., пока остаются нерешёнными задачи визуализации полупрозрачной
поверхности на глобусе, визуализации облаков точек и объемных данных на
глобусе, необходимые для создания программных систем визуализации научных
данных (в частности, подземных геофизических данных), данных лазерного
сканирования и других видов данных, которые появляются в настоящее время как
следствие использования новых методов и аппаратуры зондирования.
Цель диссертационной работы состоит в создании алгоритмического и
программного обеспечения формирования и визуализации пространственной
географической информации.
Для достижения поставленной цели необходимо было решить следующие
задачи:
разработать способ визуализации глобуса с полупрозрачной
поверхностью с возможностью как надземного, так и подземного просмотра;
разработать алгоритмы визуализации облаков точек и объемных данных
с учетом особенностей виртуального глобуса и виртуального окружения;
разработать программный комплекс для стереоскопической
визуализации данных на виртуальном глобусе, проектирования, конструирования
в общегеографическом контексте.
6
Научная новизна:
1. Разработан новый способ визуализации виртуального глобуса, который
позволяет, благодаря полупрозрачной поверхности, визуализировать 3D-объекты
под поверхностью глобуса и обеспечить отсутствие графических артефактов,
связанных с полупрозрачностью, и возможность как надземного, так и
подземного просмотра.
2. Разработан новый алгоритм визуализации облаков точек, характерной
особенность которого является использование географических координат,
возможность работы с облаками точек любого размера и динамическая
фильтрация точек на графическом процессоре по заданным критериям.
3. Разработан новый алгоритм визуализации объемных данных на
виртуальном глобусе, который работает с данными в географической системе
координат и при визуализации учитывает форму глобуса.
Практическая значимость.
Результаты работы были использованы для создания интерактивного
научно-популярного приложения «Виртуальная Долина гейзеров», которое было
внедрено и используется в музее Кроноцкого государственного природного
биосферного заповедника.
Результаты работы были использованы для реалистичной визуализации
горнолыжных трасс для горнолыжного тренажера в Московском физико-
техническом институте. Диссертант является соавтором статьи по горнолыжному
тренажеру, которая была доложена на конференции Cyberworlds 2011 и получила
награду Best Paper Award.
Результаты работы также внедрены в Институте проблем безопасного
развития атомной энергетики Российской академии наук, Всероссийском научно-
исследовательском институте по эксплуатации атомных электростанций,
Институте истории естествознания и техники Российской академии наук,
Институте физико-технической информатики.
Основные положения, выносимые на защиту:
7
1. Способ визуализации виртуального глобуса с полупрозрачной
поверхностью рельефа, который обеспечивает как надземный, так и подземный
просмотр геометрических объектов под поверхностью глобуса и устраняет
графические артефакты, вызванные перекрытием слоев рельефа и
вспомогательной геометрии.
2. Алгоритм визуализации облаков точек на глобусе с уровнями
детализации, учетом формы глобуса, контролем плотности точек на экране и
фильтрации по заданным критериям на графическом процессоре.
3. Алгоритм визуализации объемных данных, заданных в географической
системе координат и учитывающий форму глобуса.
Достоверность изложенных в работе результатов обеспечивается
корректным применением аппарата компьютерной геометрии и графики,
подтверждена экспериментальным тестированием алгоритмов и программ,
результатами опытной эксплуатации разработанных программных средств.
Апробация работы.
Основные результаты диссертации докладывались на следующих
конференциях: международных конференциях MEDIAS 2010, MEDIAS 2011,
MEDIAS 2012 (2010 г., 2012 г., г. Лимассол, Республика Кипр), Графикон 2010
(2010 г., г. Санкт-Петербург), Графикон 2012 (2012 г., г. Москва), «Ситуационные
центры и информационно-аналитические системы класса 4i» (2011 г., г. Москва),
на 53-й научной конференции МФТИ (2010 г., г. Долгопрудный), на 54-й научной
конференции МФТИ (2011 г., г. Долгопрудный), на 3-й научно-технической
конференции «Проблемы комплексного геофизического мониторинга Дальнего
Востока России» (2011 г., г. Петропавловск-Камчатский).
Результаты работы демонстрируются посетителям Постоянно действующей
выставки достижений РАН. В августе 2012 результаты работы были
представлены участникам 33-й Генеральной ассамблеи Европейской
сейсмологической комиссии и были высоко оценены ими.
Работа велась в том числе в рамках грантов РФФИ 12-07-31043 мол_а, 10-
07-00407-а.
8
Публикации. Основные результаты по теме диссертации изложены в 12
научных работах, 4 из которых опубликованы в изданиях, рекомендованных ВАК
Минобрнауки России.
Структура и объем диссертации
Диссертация состоит из введения, 4 глав, заключения, словаря терминов,
библиографии и 4 приложений. Общий объем диссертации 143 страницы, из них
113 страницы текста, включая 70 рисунков. Библиография включает 144
наименований на 12 страницах.
9
ГЛАВА 1. Методы построения и визуализации виртуальных
глобусов
1.1. Прошлое и настоящее виртуальных глобусов
1.1.1. Географическая визуализация до виртуальных глобусов
Одно из самых важных применений виртуальных глобусов — это
географическая визуализация. В статье [13] приводится определение
географической визуализации: это применение графического представления
данных для облегчения пространственного понимания вещей, понятий, условий,
процессов и событий в человеческом мире.
Считается, что одним из первых случаев применения географической
визуализации является «холерная карта» Джона Сноу (рис. 1.1). В 1854 Сноу
обозначил на карте Лондона случаи заражения холерой и отметил все водяные
насосы для подачи питьевой воды. Большинство случаев заражения
концентрировались вокруг одного насоса. Сноу использовал карту для
подтверждения свой теории, что источником заражения является этот насос [14].
В результате роста научного знания к середине 20го века появилось
множество теорий, описывающих геопространственные процессы (геологические,
климатические, экономические и антропологические теории), результаты которых
необходимо было отображать на географических картах.
В начале 1960-х годов развитие компьютеров привело к появлению первых
геоинформационных систем (ГИС) [15].
ГИС — это система для сбора, хранения, анализа и визуализации
геопространственных данных и связанных с ними атрибутов. ГИС развивают
идею Джона Сноу по наложению на географические карты дополнительных слоев
данных с целью их учета и анализа. Первые ГИС развивались с государственной
поддержкой (ГИС Канады) и использовались для городского планирования,
переписи населения [16].
10
Рис. 1.1. Холерная карта Джона Сноу
В начале 1980-х годов начали появляться коммерческие ГИС. Одна из
самых известных компаний-разработчиков ГИС ESRI выпустила свой продукт
ARC/INFO в 1982 г. ГИС стали доступны широкому кругу пользователей и
превратились в мощный инструмент для работы с картографическими данными и
тематическими геоданными [17].
Постепенно стал доступен сетевой доступ к данным, а с развитием
высокоскоростного интернета стал распространяться способ работы с ГИС через
тонкие клиенты (браузеры). В настоящее время карты уже не являются
статическими, а генерируются в процессе работы на основе информации из базы
данных по запросу пользователя. Возможно динамические объединение
информации из разных источников, разных сайтов, встраивание
картографических сервисов на любой сайт.
Параллельно с развитием классических 2D ГИС в 1990-х годах возникает
концепция 3D ГИС [18]. 3D ГИС позволяет изучать трехмерный рельеф с любых
11
точек зрения, городские сооружения и инфраструктуру, визуализировать
проектируемые здания, планировать развитие территорий, производить оценку
высотных характеристик, области видимости, проводить визуальный анализ.
Однако внедрение 3D ГИС идет медленно. В работе [19] перечисляются
основные причины этого:
организация 3D-данных. Существуют разные методы представления 3D-
моделей. У каждого есть свои преимущества и недостатки. Не ясно, в каком виде
хранить модели в базах данных предпочтительнее и как конвертировать между
разными представлениями;
реконструкция 3D-объектов. 3D ГИС должны иметь возможность
просмотра моделей реальных объектов. Для этого необходимо выполнить их 3D-
реконструкцию. Быстрые методы реконструкции выдают грубые и не точные
модели. Более детальные модели выполняются вручную или полуавтоматически и
требуют много времени. Реконструкция большого числа объектов (3D-городов) —
крайне затратная операция;
3D-визуализация. Для реалистичной визуализации 3D-объектов
необходимо решить ряд задач: разработать алгоритмы освещения, затенения,
анимации объектов, поддержать уровни детализации, туман, навигацию по
трехмерной сцене, взаимодействие с 3D-объектами. При этом технологии
постоянно развиваются и усложняются, растут требования к реалистичности.
В нескольких регионах России в 2010-2012 гг. начались пилотные проекты
по внедрению 3D ГИС [20-22]. Виртуальные глобусы — это дальнейшее
логическое развитие идеи 3D ГИС.
1.1.2. Первые виртуальные глобусы
В работе с 2D- и 3D-представлением геоданных существует большая
разница. Для 2D-данных (как растровых, так и векторных) давно разработаны
алгоритмы визуализации, анализа, хранения, используются стандартные форматы
и множество программных продуктов для разных задач.
12
Рис. 1.2. Виртуальный глобус в игре X-COM: UFO Defense (1994 г.)
Но для визуализации виртуального глобуса необходимы трехмерная
графика и большие объемы данных, а главным требованием является
интерактивная частота кадров (не менее 30 кадров в секунду). При этом не
существует общепринятых стандартов к работе с данными на виртуальном
глобусе, к навигации в пространстве виртуального глобуса. Всё это замедляет
внедрение виртуальных глобусов для решения практических задач.
В 80-е годы и начале 90-х годов основным ограничителем являлась
мощность видеокарт. Глобусы использовались для показа простейших векторных
данных, таких как границы континентов и государств, орбиты космических
аппаратов (рис. 1.2).
В 90-е годы мощность персональных компьютеров позволила использовать
более детализированные текстуры земной поверхности. В конце 90-х годов
появились такие продукты как Encarta Virtual Globe компании Microsoft (1998 г.) и
3D World Atlas компании Cosmi Corporation (1999 г.) (рис. 1.3). Это были
мультимедийные приложения, где глобус сочетался с разнообразной
энциклопедической информации о странах мира. Разрешение текстур было
невысоким, поэтому они помещались на обычные CD-диски [23, 24].
13
Рис. 1.3. 3D World Atlas (1999 г.)
Параллельно с этим в 90-е годы была заложена идеологическая основа
виртуальных глобусов. Так в 1992 году вышел роман Нила Стивенсона «Лавина»
в жанре киберпанк, в котором было описано приложение «Земля» для доступа к
разнообразным данным. Впоследствии роман оказал влияние на создателей
виртуального глобуса Google Earth [25].
31 января 1998 г. вице-президент США Альберт Гор произнес речь
«Цифровая Земля: понимание нашей планеты в XXI веке», в которой он
предложил создать «Цифровую Землю» — приложение, которое должно
включать все увеличивающее количество геоданных, быть подсоединено к базам
данных и знаний всего мира и обеспечить лучшее описание и понимание
окружающего мира и человеческой деятельности [26].
В конце 90-х — начале 2000-х гг. произошел перелом в развитии
виртуальных глобусов. Это связано со следующими факторами.
Частные компании, такие как GeoEye и Digital Globe, начали запускать
спутники дистанционного зондирования для получения снимков высокого
разрешения (до 0,5 метра) [27, 28]. NASA запустило миссию SRTM по созданию
общедоступной цифровой модели рельефа для всей Земли [29].
Полученные со спутников данные имеют огромные размеры. Можно грубо
сделать следующую оценку: для хранения текстуры всей Земли с разрешением
0.5м/пк нужно 11 петабайт. Даже если выкинуть все моря, океаны, пустыни и
14
полюса, всё равно остаётся внушительное число. На CD-диск эти текстуры уже не
поместятся.
В это же самое время появился высокоскоростной доступ к интернету.
Возникла идея размещать геоданные на серверах в интернете, а на компьютеры
пользователей устанавливать клиентское программное обеспечение (ПО), которое
должно скачивать изображения только той части поверхности Земли, которая
нужна пользователю.
Также в это время рост рынка компьютерных игр привел к жесткой
конкуренции между производителями видеокарт. Слабые игроки были либо
вытеснены с рынка, либо куплены более сильными игроками. В начале 2000-х
годов остались две основные компании: NVIDIA и ATI (позже перешла под
контроль AMD). Конкуренция привела к быстрому развитию видеокарт и
переносу графических вычислений на графический процессор [30]. Это развитие
позволило интерактивно визуализировать на экране компьютера модель глобуса с
текстурами и рельефом высокого разрешения и различными эффектами.
Таким образом, указанные 3 фактора (появление данных ДЗЗ высокого
разрешения, развитие интернета и видеокарт) стали толчком для появления
виртуальных глобусов нового поколения и роста интереса к глобусам в мире.
Компания Keyhole одной из первых начала развивать свой продукт в 2001
году на базе этой идеи. Впоследствии она была куплена компанией Google.
Переименованный в Google Earth продукт вышел в 2005 году для свободного
использования [31]. Параллельно NASA выпустила свой продукт World Wind в
2004 году и Microsoft выпустила Virtual Earth (ныне Bing Maps 3D) в 2006 году.
Google Earth стал по-настоящему массовым продуктом и популяризовал
идею виртуальных глобусов [32]. Разработчики ГИС также стали внедрять у себя
возможность просмотра геопространственных данных на глобусе (ArcGIS,
gvSIG). Учёные начали публиковать свои данные в открытом формате KML для
просмотра результатов на глобусе.
Далее рассмотрим более подробно глобусы Google Earth и NASA World
Wind.
15
1.1.3. Google Earth
Google Earth — виртуальный глобус компании Google, который был куплен
у компании Keyhole (рис. 1.4). GE — бесплатен для некоммерческого
использования, но имеет закрытый исходный код. Также имеются платная версия
с расширенным функционалом. GE поддерживает операционные системы
Windows, Linux, Mac OS X, iOS и Android [33].
В GE используются коммерческие спутниковые и аэрофотоснимки
высокого разрешения до 0.15м/пк. Также возможен просмотр исторических
снимков.
Рис. 1.4. Виртуальный глобус Google Earth
GE позволяет просматривать также карту звездного неба и снимки Луны и
Марса. Имеется встроенный авиасимулятор. GE позволяет просмотр
пользовательских геоданных в формате KML: векторные данные, растровые
данные и 3D-модели. Также GE позволяет добавление и редактирование
собственных данных и сохранение их в формате KML. Имеется множество
встроенных слоев данных: 3D-здания, границы государств, названия
географических объектов, дороги, фотографии разных мест.
1.1.4. NASA World Wind
NASA World Wind — это виртуальный глобус, разрабатываемый NASA и
сообществом открытого программного обеспечения (рис. 1.5). Он позволяет
просматривать спутниковые снимки Земли, Луны, Марса, Юпитера, некоторых
его спутников и карту звёздного неба [34].
16
Рис. 1.5. Виртуальный глобус NASA World Wind 1.4.0 (14.02.2007)
Основные отличия от Google Earth: полностью бесплатен, в том числе для
коммерческого использования; имеет открытый исходный код, который можно
использовать для создания своих приложений на базе WW; использует
бесплатные снимки Земли: на мелких масштабах — Blue Marble NG, на крупных
масштабах — Landsat 7, но при этом позволяет брать данные и из других
источников.
Первая версия WW вышла в 2004 году, была написана на C# и работала
только под Windows. Разработка этой версии прекращена в 2007 году, и поэтому
имеются проблемы совместимости с Windows Vista/Windows 7. Некоторый
функционал недоступен, в частности модуль Scientific Visualization Studio,
который позволяет просматривать анимацию многих природных явлений
(пожаров, ураганов).
1.1.5. Неогеография
Рывок технического прогресса в области виртуальных глобусов и появление
Google Earth привели к широкому распространению термина «неогеография».
Хотя этот термин и использовался раньше, в современном смысле он был
рассмотрен в 2006 году в книге Эндрю Тернера «Введение в неогеографию» [35].
17
Термин «неогеография» означает совокупность новых методов и средств
для работы с геоданными [36]. Можно выделить три основных отличия от
традиционного подхода:
использование географических систем координат (долгота, широта и
высота), а не картографических;
использование растрового представления информации как основного;
использование открытых форматов данных.
В традиционных ГИС используются картографические проекции, а данные
хранятся в основном в векторной форме. Это было необходимо, т.к. во времена
первых ГИС компьютеры были менее производительны, чем сейчас, а векторные
данные занимают меньше места и требуют меньше вычислительных ресурсов.
Однако картографические проекции приводят к геометрическим
искажениям: искажениями длин, площадей и углов. А векторные данные не полно
и не точно отражают окружающую действительность.
Современные компьютеры могут легко работать, как с векторными, так и с
растровыми данными ДДЗ, наложенными на виртуальный глобус. Также есть
возможность отображения любых 3D-моделей на глобусе. Это позволяет
отказаться от условных обозначений и заменить их приближенными к реальности
3D-моделями.
Неогеография предполагает обмен геопространственными данными между
различными приложениями и для этого использование открытых
стандартизованных форматов данных. Одним из таких форматов является KML
(Keyhole Markup Language), который был изначально разработан для Google Earth
и впоследствии был стандартизован. Сейчас этот формат поддерживают
большинство ГИС и виртуальных глобусов.
Однако в среде профессиональных географов термин был встречен
неоднозначно. Доктор географических наук А.М. Берлянт подверг критике
термин «неогеография» в нескольких свои работах [37]. Основные положения:
этот термин используется для влияния на «администраторов, распоряжающихся
18
денежными суммами», неогеография подразумевает отказ от условного,
знакового обозначения объектов [38].
1.1.6. Современные тенденции в развитии виртуальных глобусов
Google Earth хорошо подходит для просмотра спутниковых снимков и
готовых геопространственных данных. Но полноценная работа и анализ данных
невозможны. GE нельзя расширять, усовершенствовать, добавлять свои типы
данных и интегрировать с другими приложениями. У GE закрытые исходники и
нет программного интерфейса (API), кроме браузерной версии.
Сейчас мы находимся на этапе, когда происходит применение виртуальных
глобусов для реальных практических задач, проводятся исследования,
разрабатываются новые виртуальные глобусы и идеи их применения. Можно
привести несколько работ в этой области.
В Институте геодезии и геоинформатики Университета прикладных наук
Северо-Западной Швейцарии с середины 2000-х годов разрабатывается
виртуальный глобус i3D для научно-исследовательских целей [39].
В работе Schafhitzel T., Falk M., Ertl T. 2007 года [40] описывается
реалистичный рендеринг планет с атмосферой в реальном времени.
В работе Schoning J., Hecht B., Raubal M. 2008 года [41] предлагается
улучшение взаимодействия с виртуальным глобусом с помощью сенсорного
экрана с множественным касанием (multitouch). Там же указывается на важность
ответов на вопрос «Почему здесь это находится?», а не только «Что здесь
находится?» при работе с виртуальным глобусом.
В работе Christen M. 2008 года [42] рассматривается идея применения
трассировки лучей для рендеринга виртуальных глобусов, а также приводится
набор необходимых улучшений для повышения реализма: процедурная генерация
текстур на основе спутниковых данных, реалистичные облака, вода и
растительность.
В 2009 году был разработан виртуальный глобус Crusta [43] специально для
задач геологии. Упор был сделан на точную и интерактивную визуализацию
19
высокодетализированных данных (меньше 1м/пиксель). Глобус использует
многогранник из 30 граней, что позволяет уменьшить искажения и устанить
сингулярность на полюсах. Далее каждая грань рекурсивно делится на
четырехугольники.
В 2010 группа немецких исследователей в рамках проекта EuroSDR
(European Spatial Data Research) провела опрос участников геоиндустрии об
использовании виртуальных глобусов и затем опубликовала отчет [44]. Основные
выводы: виртуальные глобусы оказывают положительное влияние на индустрию
и это направление будет развиваться и дальше. Основные проблемы: отсутствие
стандартизации этой области и необходимость в больших вычислительных
мощностях и новых геоинструментах.
Технология лидарной съемки позволяет восстанавливать трехмерный
рельеф по облаку точек. В статье Christen M., Nebiker S. 2011 года описывается
модификация алгоритма триангуляции Делоне для быстрого построения
трехмерного рельефа виртуального глобуса с уровнями детализации [45].
В статье Nebiker S., Bleisch S., Christen M. авторы предлагают новый подход
к построению 3D-моделей городов, основанный на использовании облаков точек
лазерного сканирования на виртуальном глобусе [46].
В 2011 была Bleisch S. защищена диссертация по оценке пригодности
визуального комбинирования количественных данных при визуализации на
виртуальном глобусе [47].
В 2011 году вышла монография «3D Engine Design for Virtual Globes» [48],
полностью посвященной вопросам разработки приложений с использованием
виртуальных глобусов. В книге рассматриваются основные вопросы и задачи,
которые возникают при разработке глобусов: системы координат, математика
эллипсоида, проблема точности и дрожания (jittering), рендеринг векторных
данных на глобусе, рендеринг рельефа.
Усилия разработчиков тратятся сейчас на поддержку визуализации
различных типов векторных данных на глобусе, 3D-моделей, поддержку очень
больших массивов данных: задачи динамической подгрузки и выгрузки.
20
Другое направление развития — увеличение реализма визуализации. Сейчас
уже поддержаны визуализация атмосферы для любых высот над Землей,
визуализации 3D-моделей зданий больших городов. Интересно отметить проект
Outerra, разработчики которого добавляют фрактальную детализацию к данным
ДЗЗ, генерируют процедурные дороги, леса и различные природные эффекты
(рис. 1.6). Детали реализации разработчики раскрывают в блоге проекта [49].
Существуют такие задачи, как реалистичная вода, динамические тени, смена
времен года.
Рис. 1.6. Виртуальный глобус Outerra
Визуализация данных на виртуальном глобусе также входит и в
повседневную жизнь. Многие имеют телефоны со встроенными GPS или
ГЛОНАСС датчиками. Это позволяет отображать на глобусе маршруты своих
передвижений, добавлять географическую привязку к фотографиям и сообщениям
в переписке с другими людьми.
Возникают проекты, в том числе с открытым исходным кодом, которые
позволяют формировать виртуальный глобус на основе современных
спутниковых снимков и цифровых моделей рельефа. Один из примеров — NASA
World Wind Java SDK, выпущенный в 2007 году. Другой — библиотека osgEarth,
разработка которой началась в 2008 году на языке С++.
Эти проекты позволяют внедрять возможности виртуального глобуса в
другие приложения. Они берут на себя генерацию глобуса из данных ДЗЗ,
позволяя пользователям подключать любые типы и источники данных,
21
разрабатывать приложения для анализа данных на основе глобуса. Подробнее они
рассмотрены в следующем параграфе.
1.2. Обзор программных решений и открытых стандартов
Существует несколько программных решений, имеющих программный
интерфейс (API), который обеспечивает возможность написания производных
приложений для работы с данными на виртуальном глобусе.
1.2.1. Google Earth browser plug-in
Первые версии приложения Google Earth имели COM API, который
позволял писать расширения. Однако в последних версиях его отключили [50].
Вместо этого в 2008 году Google выпустил специальную версию Google Earth в
виде плагина для браузера, который можно встраивать на веб-странички. Этот
плагин обладает своим API, который позволяет управлять визуализацией данных
в GE с помощью языка JavaScript [50]. Плагин работает только в операционных
системах Windows и Mac OS X.
Функционал плагина для браузера повторяет функционал основной версии.
Возможны создание, изменение и визуализация векторных данных: меток,
ломаных линий, полигонов, 3D-моделей, аннотаций, наложений, управление
камерой, запись и воспроизведение виртуальных туров. В основной версии все
эти действия пользователь может выполнять мышкой. В браузерной версии эти
действия могут быть автоматизированы программным образом. Можно загружать
данные из разных источников, анимировать их, реагировать на действия
пользователя.
Реализовать принципиально новый функционал API не позволяет. Поэтому
возможное применение плагина Google Earth сильно ограничено.
1.2.2. NASA World Wind Java SDK
Первая версия NASA World Wind, вышедшая в 2004 году, была основана на
платформе .NET работала только под Windows.
22
В 2007 году началась разработка новой версии NASA World Wind на языке
Java [51]. Она называется World Wind Java SDK, имеет открытый исходный код,
работает на любых операционных системах с поддержкой Java и OpenGL, и
может встраиваться на веб-странички в виде Java-апплета.
World Wind Java SDK — это не готовое приложение, а набор компонентов,
которые можно использовать для разработки собственных приложений для
визуализации и анализа геопространственных данных на виртуальном глобусе,
можно интегрировать в существующие приложения на Java. Вместе с WW Java
SDK идёт набор демонстрационных приложений, каждое из которых
иллюстрирует отдельные возможности WW.
Основные возможности: загрузка изображений поверхности Земли и карт
высот из разных интернет-источников, доступных по протоколу WMS;
использование локальных данных; экспорт текстур и карт высот в виде отдельных
GeoTIFF-файлов; чтение векторных форматов файлов (KML, Shapefile);
визуализация векторных данных (точки, линии, полигоны); визуализация 3D-
моделей и аннотаций. Графический интерфейс пользователя реализуется через
библиотеки AWT и Swing.
Благодаря открытости исходного кода, все эти компоненты можно
дополнять, расширять и модифицировать под нужны конкретной задачи.
1.2.3. osgEarth
osgEarth — инструментарий с открытым исходным кодом для рендеринга
рельефа и данных на рельефе виртуального глобуса [52]. osgEarth выпущен под
лицензией LGPL и написан на C++. osgEarth основан на OpenGL и является
надстройкой над графическим инструментарием OpenSceneGraph. osgEarth
работает на любых операционных системах, которые поддерживают OpenGL,
включая мобильные iOS и Android.
Также как и WW Java SDK, osgEarth можно использовать для разработки
собственных приложений, либо для интеграции виртуального глобуса в
существующие приложения.
23
Одно из основных отличий osgEarth в том, что исходные растровые данные
для построения рельефа не обязательно заранее обрабатывать. osgEarth может
работать с «сырыми» данными и генерировать рельеф динамически во время
работы приложения. Предобработка данных может ускорить этот процесс.
Генерируемый рельеф автоматически кэшируется, что позволяет ускорить работу
приложения при последующих запусках.
Основные возможности такие же, как и в WW Java SDK: загрузка
изображений поверхности Земли и карт высот из разных интернет-источников по
протоколам WMS, WCS, TMS; использование локальных данных; чтение
векторных форматов файлов (KML, Shapefile); визуализация векторных данных
(точки, линии, полигоны); визуализация 3D-моделей и аннотаций. Добавить
графический интерфейс пользовать можно либо с помощью фреймворка Qt, либо
встроенной библиотеки виджетов.
Конфигурировать глобус можно либо в коде на C++, либо с помощью
специального файла в формате XML. В нем указываются пути к слоям
изображений, карт высот, пути к файлам с векторными данными. Можно задавать
стили в формате CSS для векторных данных в зависимости от их атрибутов.
Также можно использовать JavaScript для этих целей.
osgEarth может разбивать большие массивы векторных данных тайлы с
уровнями детализации и подгружать их при приближении. Авторы osgEarth
разработали протокол Tile Feature Service (TFS) для быстрой подгрузки таких
данных в osgEarth [53].
1.2.4. Протоколы передачи данных
Существует множество открытых стандартов для хранения и передачи
геопространственных данных. Стандартизацией занимается Открытый
геопространственный консорциум, основанный в 1994 году. Все стандарты
поддерживаются множеством приложений и библиотек, как проприетарных, так и
свободных.
24
Web Map Service (WMS) — стандартный протокол для получения
растровых изображений через интернет [54]. Был опубликован в 1999 году.
Работает поверх протокола HTTP. Изображения могут генерироваться
динамически на сервере, либо браться из кэша. WMS поддерживает 2 типа
запросов: GetCapabilities для получения параметров WMS-сервера и GetMap для
получения изображения с заданными границами, размерами и системой
координат.
Недостатком WMS является то, что размеры запрашиваемого изображения
могут быть любыми. Это затрудняет кэширование результатов и приводит к
необходимости при каждом запросе генерировать выходное изображение заново.
Предложено несколько модификаций для решения этого. Например, WMS-C и
Tiled Web Map Service, которые допускают только запросы изображений с
определенными границам.
Tile Map Service (TMS) — спецификация хранения растровых
картографических данных в виде множества тайлов разных уровней детализации,
распределенных по папкам [55]. Зная стандартную структуру папок, клиентское
приложение может запрашивать необходимые тайлы с сервера по URL.
Web Map Tile Service (WMTS) — протокол для получения растровых
изображений, который пришел на смену TMS и решает проблемы WMS [56]. Был
опубликован в 2010 году. При получении запроса сервер может отправить либо
изображение из кэша, либо сгенерировать его динамически.
Web Coverage Service (WCS) — протокол для получения покрытий через
интернет [57]. Под покрытием подразумеваются данные, протяженные в
пространстве и изменяющиеся во времени. В отличие от WMS, который
возвращает статические изображения, WCS возвращает дополнительно
метаданные, которые позволяют далее взаимодействовать с покрытием на
клиенте.
Web Feature Service (WFS) — протокол для получения географических
объектов через интернет [58]. Позволяет получать список объектов в заданной
25
области, создавать новые объекты, удалять и изменять объекты. Сами данные
передаются с сервера на клиент в формате Geography Markup Language (GML).
1.2.5. Форматы данных
Существует большое количество разнообразных форматов для хранения
растровых и векторных данных.
GeoTIFF — формат для хранения растровых данных. Добавляет
специальные метаданные к изображению: систему координат, проекцию,
эллипсоид, датум, размеры и границы изображения.
Geography Markup Language (GML) — формат, основанный на нотации
XML, для описания и хранения геопространственных данных. Формат может
включать любую географическую информацию. Благодаря своей
универсальности, формат используется для обмена данными между различными
приложениями.
Keyhole Markup Language (KML) — формат, который используется для
визуализации геопространственных данных [59]. Этот формат был разработан и
начал использоваться в приложении Google Earth. Сейчас это открытый стандарт
[60], и его поддерживает множество разных приложений. KML-файлы часто
распространяются в виде ZIP-архива с расширением .kmz. В этом случае архив
может также содержать дополнительные файлы: изображения, звуковые файлы,
3D-модели.
KML может содержать информацию геометрию (точки, линии, полигоны,
3D-модели), накладываемые изображения, аннотации. 3D-модели и сами
изображения хранятся во внешних файлах, а в KML-файле содержатся только
ссылки. Все координаты задаются в географической системе координат WGS84.
Высоты можно задавать абсолютно или относительно рельефа. Внешний вид
геометрии и задается с помощью стилей.
Дополнительно можно задавать положения камеры при просмотре и даже
целые виртуальные «путешествия», которые включают подлеты к заданной точке,
паузы, звуковые вставки, запуск аннотаций, изменение видимости геометрии.
26
Shapefile — формат хранения векторных геопространственных данных.
Разработан компанией ESRI [61]. Не является открытым стандартом, однако это
стандарт для обмена данными между геоинформационными системами. Помимо
геометрических данных позволяет хранить атрибутивные данные.
1.3. Генерация рельефа для виртуальных глобусов
В основе визуализации рельефа для виртуальных глобусов лежат те же
алгоритмы, что и для «плоского» рельефа, но с некоторыми модификациями.
При визуализации рельефа можно выделить две основные фазы: (1)
генерация геометрии рельефа и (2) текстурирование и освещение этой геометрии.
Рассмотрим подробнее первую фазу. Вторая будет освещена во второй
главе.
1.3.1. Генерация трехмерного рельефа
Существует множество разных методов создания трехмерного рельефа.
Рассмотрим основные из них.
Полигональные поверхности. Трехмерный рельеф аппроксимируется
полигональной поверхностью. Высота точек поверхности берется из карты высот.
Есть несколько вариантов построения полигональной поверхности:
регулярная сетка — вершины расположены через равные интервалы.
Каждому пикселю карты высот соответствует своя вершина сетки. Это наиболее
простой метод;
нерегулярная сетка (TIN, Triangular Irregular Network) — в местах
быстрого перепада высот плотность вершин делается выше, в более ровных
местах — ниже. Это позволяет уменьшить количество полигонов, но требует
большего времени на построение.
Генерация, использование и текстурирование нерегулярных сеток –
довольно сложная задача. Они могут дать выигрыш, если большая часть рельефа
плоская и сам рельеф небольшого размера.
27
Поэтому на практике для больших территорий применяются регулярные
сетки, которые удобнее в работе и проще строятся. А уменьшение количества
полигонов можно достичь с помощью уровней детализации. К тому же развитие
производительности видеокарт сводит на нет преимущества нерегулярных сеток
[62].
Уровни детализации (LOD, Level of Detail). Но для больших территорий
использование одной большой полигональной поверхности не выгодно. Большая
3D-модель рельефа занимает видеопамять и процессорное время. В каждый
момент времени видна лишь небольшая часть большой территории. А если
отдалиться и посмотреть на всю территорию целиком, то детализация
поверхности будет слишком избыточной.
Поэтому применяются уровни детализации рельефа. Издалека виден грубый
рельеф, а при приближении детализация полигональной поверхности
увеличивается.
Существуют алгоритмы для непрерывных уровней детализации. Например,
ROAM (Real-Time Optimally Adapting Meshes) [63]. Заранее строится двоичное
дерево, каждый узел которого содержит один треугольник, а два дочерних узла –
половинки этого треугольника.
Во время работы приложения происходит динамическая подстройка сетки –
рядом с наблюдателем число треугольников делается выше, а чем дальше, тем
ниже. Это происходит в реальном времени при перемещении наблюдателя.
Вычисляются ошибки отклонения вершин, и при необходимости треугольник
разбивается на две половины.
При этом расчет сетки полностью ложится на центральный процессор.
Поэтому этот метод проигрывает по быстродействию другим алгоритмам, хотя и
обеспечивает большую точность.
Наиболее часто применяются дискретные уровни детализации.
Формируется пирамида уровней детализации. Каждый следующий уровень имеет
разрешение в 2 раза выше. Каждый уровень детализации разбивается на тайлы
равного размера. Издалека виден грубый рельеф с низким разрешением. При
28
приближении он заменяется на 4 тайла с более высоким разрешением и т.д.
Каждый тайл имеет свою карту высот и свою текстуру.
В этой ситуации возникает проблема сшивки тайлов. Если два находящихся
рядом тайла имеют разные уровни детализации, то между ними могут возникать
щели. Это решается добавлением «юбок» к тайлам. Юбка — вертикальная
полоска треугольников по периметру тайла (рис. 1.7).
В работе Livny Y., Kogan Z., El-Sana J. предложен алгоритм бесшовного
стыка тайлов [64].
В случае дискретных уровней детализации может возникать эффект скачков
(popping), когда при смене тайлов разных уровней детализации виден резкий
скачок некоторых частей рельефа. Этот эффект проявляется при медленной
подгрузке новых тайлов с диска или из интернета. Одно из возможных решений:
плавная интерполяция между тайлам. Она, конечно, будет замета, но не будет
сильно резать глаза.
Рис. 1.7. Слева - щель между тайлами, справа - закрытие щели с помощью юбки
Geometry Clipmaps. Особняком стоит алгоритм Geometry Clipmaps [65]. Он
не использует разбиение геометрии на тайлы. Вокруг наблюдателя генерируется
набор плоских вложенных регулярных полигональных сеток. Чем дальше от
наблюдателя, чем ниже разрешение сетки. Параметры подбираются так, чтобы
размер треугольников на экране был примерно одинаковым. При движении
наблюдателя сетки движутся вместе с ним (рис. 1.8).
Высота вершин сетки вычисляется в вершинном шейдере на основе карт
высот. Используется пирамида карт высот разного разрешения для разных сеток.
29
Рис. 1.8. Вложенные сетки в алгоритме Geometry Clipmapping
При движении наблюдателя сетки движутся вместе с ним. При этом
текстура рельефа и карта высот динамически обновляются: часть текстуры
удаляется, и на ее место подгружается кусок с диска. Используется тороидальный
доступ. Это позволяет использовать текстуры и карты высот теоретически
неограниченного размера.
1.3.2. Разбиение поверхности глобуса на тайлы
В методе дискретных уровней детализации необходимо разбивать каждый
уровень на прямоугольные кусочки — тайлы. В случае «плоского» рельефа
естественным является рекурсивное разбиение пространства на квадраты. В
случае глобуса можно придумать много разных вариантов разбиения [48]. Вот
некоторые из них:
разбиение правильного многогранника. За основу берется, например,
тетраэдр. Далее каждая грань рекурсивно разбивается на треугольники. При
добавлении новых вершин они сдвигаются к поверхности эллипсоида;
«надутый куб». За основу берется куб. Для каждой грани куба
формируется регулярная сетка нужного разрешения. Затем каждая вершина
сдвигается к поверхности эллипсоида (рис. 1.9);
разбиение HEALPix (Hierarchical Equal Area isoLatitude Pixelization), при
котором все пиксели занимают одинаковую площадь (рис. 1.10) [66];
30
географическая сетка. Разбиение на тайлы происходит вдоль
меридианов и параллелей (рис. 1.11).
1.3.3. Географическая система координат
Эллипсоид и геоид
Для задания положения точек на глобусе обычно используется
географическая система координат: тройка чисел (долгота, широта, высота). Но на
видеокарте все расчеты происходят в прямоугольной декартовой системе
координат. Поэтому необходимо задать связь между этими системами координат.
Земля имеет сложную пространственную форму. Для упрощения
математических вычислений необходимо уметь описывать форму Земли с разной
степенью точности. Самое простое приближение — сфера — подходит только для
самых мелких масштабов. Часто используется следующее приближение —
эллипсоид (рис. 1.12). Эта геометрическая фигура образована вращением эллипса
вокруг малой полуоси.
Рис. 1.9. Разбиение «надутый куб»
Рис. 1.10. Разбиение HEALPix
31
Рис. 1.11. Разбиение по географической сетке
Ещё одно приближение – геоид, эквипотенциальная поверхность
гравитационного поля, совпадающая с морями и океанами и условно
продолженная вглубь материков. Поверхность геоида в каждой точке
перпендикулярна линии отвеса.
Т.к. эллипсоид по форме не совпадает с геоидом, то один и тот же
эллипсоид можно двигать относительно геоида, компенсируя погрешности в
одном месте и увеличивая в другом месте. Датум — это набор параметров,
которые задают смещение эллипсоида относительно геоида [67]. Датумы могут
быть локальными, т.е. обеспечивать наилучшую аппроксимацию геоида в данном
месте (например, Североамериканский датум NAD83). Также датумы могут быть
глобальными — минимизировать погрешность для всей Земли. В настоящее
время наиболее часто используется датум 1984 года World Geodetic System
(WGS84). Например, он используется в системе позиционирования GPS.
Рис. 1.12. Геоид и эллипсоид
32
В системе WGS84 используется эллипсоид с параметрами: экваториальный
радиус — 6378137м, полярный радиус — 6356752.3142м. Географические
координаты задаются относительно этого эллипсоида [68].
Мировая декартова система координат (МСК) задается следующим образом.
Ось Z проходит через северный полюс, плоскость XY — через экватор, плоскость
XY — через нулевой меридиан.
Для перехода от эллипсоида к геоиду необходимо в каждой точке задать
высоту геоида над эллипсоидом. Это отклонение невелико и составляет ± 200 м.
Существуют модели для расчета этого отклонения. Часто используется модель
EGM96. Например, она применяется для корректировки высот в системе
позиционирования GPS. Также сейчас существует усовершенствованная модель
EGM2008.
Учет формы Земли при построении виртуального глобуса
Форма полигональной поверхности глобуса зависит от цифровой модели
рельефа (ЦМР), которая используется при его построении. Если ЦМР не задана,
то поверхность принимает форму эллипсоида. Если используется ЦМР, то
вершины полигональной сетки сдвигаются по нормали на заданную высоту.
Современные ЦМР, такие как SRTM и ASTER GDEM (приложение А),
содержат высоту рельефа над геоидом EGM96. Поэтому для сдвига вершин
полигональной сетки нужно делать поправку на высоту геоида над эллипсоидом.
Существуют программные библиотеки для проведения расчетов.
При визуализации 3D-данных на глобусе нужно учитывать, как задана
высота точек. Есть три альтернативы (рис. 1.13):
1. высота задана относительно эллипсоида;
2. высота задана относительно геоида (относительно уровня моря);
3. высота задана относительно рельефа.
Имея ЦМР и геоид EGM96, можно корректно показать расположение
геопространственных 3D-данных.
33
Таким образом, точность представления данных зависит в первую очередь
от самих данных.
Рис. 1.13. Высота точки относительно разных поверхностей
Вычисление нормали
Во многих задачах связанных с визуализацией часто нужно вычислять
нормаль к поверхности эллипсоида в точке. Нужно различать геоцентрическую
нормаль и геодезическую нормаль (рис. 1.14). Геоцентрическая нормаль лежит на
линии, соединяющей центр эллипсоида и данную точку на поверхности.
Геодезическая нормаль — честный перпендикуляр к поверхности.
Геодезическая нормаль вычисляется по формуле:
, (1.1)
, (1.2)
где – вектор нормали, m – вспомогательный вектор, (a, b, c) – радиусы
эллипсоида, (xs, ys, zs) – точка на поверхности эллипсоида.
34
Рис. 1.14. Геоцентрическая и геодезическая нормали
Преобразование географических координат в декартовы довольно просто.
Иногда бывает нужно и обратное преобразование. Но оно значительно сложнее и
может приводить к неоднозначностям.
1.3.4. Особенности виртуальных глобусов
В случае рендеринга виртуального глобуса и данных на глобусе нужно
учитывать ряд нюансов и особенностей, которых нет в плоском варианте [48].
Точность координат. В настоящее время видеокарты в основном
используют при расчетах тип данных с плавающей точкой одинарной точности
(float), который имеет примерно 7 значащих десятичных цифр. Радиус Земли
также имеет 7 значащих цифр. Это приводит к ошибкам округления при
проведении матричных преобразований. Визуально это проявления в «дрожании»
(jittering) объектов рядом с камерой.
Проблема частично решается использованием операций с двойной
точностью на CPU. Результаты операций далее переводятся в одинарную
точность перед отправкой на GPU.
Точность буфера глубины. Буфер глубины (z-buffer) хранит глубину
отрисованных пикселей экрана. В случае виртуального глобуса наблюдатель
может смотреть на глобус целиком из космоса, а может подлетать к поверхности
глобуса. Это приводит к необходимости иметь очень близко ближнюю плоскость
отсечения и очень далеко дальнюю плоскость отсечения. Глубина пикселя
зависит от этих расстояний. При вычислении глубины она округляется из-за
ограниченной точности буфера глубины. Чем больше расстояние от ближней до
35
дальней плоскости отсечения, тем больше ошибка. И может оказаться так, что
дальние объекты будут закрывать ближние.
Проблема частично решается введением логарифмического буфера
глубины, что, однако, влияет на производительность приложения [69].
Аккуратность расчетов. Нужно помнить, что Земля — это эллипсоид, а не
сфера. И при осуществлении расчетов учитывать разницу между экваториальным
и полярным радиусами, разницу между геоцентрической и геодезической
нормалями. Например, при движении космических аппаратов вокруг Земли или
при позиционировании объектов на поверхности глобуса.
Кривизна. Нужно помнить, что Земля — круглая. Если соединить 2 точки
на поверхности прямой линий в декартовых координатах, то эта линия окажется
под поверхностью глобуса. Необходимо применять различные методы, чтобы все
линии и полигоны оказались на поверхности, а не под поверхностью. Нужно
помнить про линию перемены дат, и что на полюсах имеется сингулярность.
Большие объёмы данных. Виртуальный глобус строится на основе
спутниковых снимков и карт высот. Если мы заходим представить рельеф всей
Земли с разрешением 1 м на пиксель, то нам понадобится текстура 40 млн на 20
млн пикселей размером примерно в 11 петабайт. При этом возникает проблема —
ограничение видеопамяти. На современных видеокартах имеется порядка 1
гигабайта памяти. При этом существуют ограничения на размер текстур в памяти
— примерно 8192х8192 пикселей. Также существует предел обработки
количества вершин модели в секунду.
Поэтому основная проблема заключается в том, как использовать большой
объем (гигабайты и петабайты) исходных данных на жестком диске, чтобы
показать на экране рельеф с небольшим числом вершин и небольшим размером
текстур, который мог бы обновляться с частотой 30 кадров в секунду.
Использование многопоточности. Динамическая загрузка и выгрузка
данных из памяти сильно влияет на производительность. Эти операции лучше все
выполнять в отдельном потоке.
36
Алгоритмы рендеринга различных эффектов обычно используют
упрощения и предположения, которые не применимы в случае виртуальных
глобусов. Например, в обычных приложениях направление «вверх» всегда
совпадает с осью Z. В случае глобуса в каждой точке будет своё собственное
направление «вверх».
Современные компьютерные игры достигли больших успехов в
реалистичном рендеринге природы. Рельеф, деревья, трава, облака, вода — всё
генерируется программно с большой детализацией. Но в случае глобусов
приходится использовать реальные данные о рельефе, реальную текстуру земной
поверхности, которые зачастую имеют низкое разрешение. Если пытаться эти
данные улучшать и добавлять детализацию, то не в ущерб достоверности.
1.3.5. Алгоритм Chunked LOD
В итоге с учётом всех особенностей глобуса авторы книги [48] рекомендуют
использовать алгоритм Chunked Level of Detail (CLOD), как наиболее
сбалансированный по всем характеристикам. Этот же алгоритм используется в
инструментарии osgEarth. Изначально он был предложен в 2002 году [70].
Этот метод не требует предварительной обработки геопривязанных
изображений, удобно ложится на эллипсоид, обеспечивает приемлемую точность
в рамках чисел с одинарной точностью, и работает даже на самых старых
видеокартах. Рассмотрим его подробнее.
Рельеф состоит из тайлов (chunk), выстроенных вдоль меридианов и
параллелей. Каждый тайл имеет свою геометрию на основе регулярной сетки и
текстуру. Каждый тайл относится к некоторому уровню детализации. Все тайлы
образуют квадродерево. При приближении к тайлу он заменяется на 4 тайла
большей детализации. Для каждого тайла хранится ограничивающий объём,
который используется для проверки видимости тайла.
Каждый тайл должен храниться в отдельном файле. При необходимости
тайлы подгружаются в память с диска или выгружаются из памяти. Каждый тайл
содержит ссылки на файлы с 4 дочерними тайлами.
37
Структура получаемого квадродерева изображена на рисунке 1.15.
Рис. 1.15. Структура квадродерева
TerrainTile — содержит сам тайл (геометрию и текстуру). Group — просто
группирует подузлы графа. PagedLOD — переключает тайлы с разными уровнями
детализации.
1.4. Выводы по 1 главе
В главе приведен анализ современных методов, применяемых для
построения и визуализации виртуальных глобусов и географической
визуализации, обзор современного состояния дел, на основании которого сделаны
следующие выводы:
1. Существуют готовые закрытые продукты для просмотра спутниковых
снимков (Google Earth), открытые библиотеки для разработки производных
приложений (osgEarth, NASA WorldWind Java SDK), глобусы для научных задач
(Crusta, i3D). Исследования ведутся по направлениям: увеличение реализма
визуализации глобуса и 3D-объектов на глобусе (освещение, вода, облака, тени,
деревья, дома) и внедрение глобуса для решения практических задач. Существуют
38
стандартные протоколы передачи геопространственных данных и стандартные
форматы для хранения данных.
2. При визуализации данных на глобусе нужно учитывать ряд особенностей
по сравнению с плоским случаем: точность координат типа float, точность буфера
глубины, форму Земли (эллипсоид и геоид) и соответствующие особенности
вычисления расстояний и нормалей, большие объемы растровых данных.
3. Алгоритмы для генерации трехмерного рельефа глобуса являются
производными от алгоритмов для плоского случая. Могут быть использованы
регулярные и нерегулярные сетки, уровни детализации: непрерывные и
дискретные, алгоритм Geometry Clipmapping. Все они адаптируются для случая
виртуального глобуса. При этом существуют несколько вариантов разбиения
поверхности глобуса на тайлы. Варианты имеют свои плюсы и минусы.
4. В данной работе исследовании на основе проведенного анализа выбран
алгоритм Chunked Level of Detail [48]. В нем используются дискретные уровни
детализации, тайлы рельефа образуют квадродерево, каждый тайл основан на
регулярной сетке, глобус разбивается на тайлы по географической сетке. В
качестве программной реализации выбран инструментарий osgEarth.
39
ГЛАВА 2. Визуализация виртуального глобуса
2.1. Варианты отображения виртуального глобуса
Виртуальный глобус может применяться для различных задач: от
фотореалистичного рендеринга территорий до визуализации научных данных. В
разных ситуациях глобус можно отрисовывать с различными настройками, в
различных режимах. Для решения одних задач нужна максимальная
реалистичность, в других задачах нужно выделить особенности данных,
представить данные более наглядно. В этом параграфе рассматриваются
существующие основные режимы отображения глобуса.
2.1.1. Варианты условного отображения глобуса
Для визуализации научных или статистических данных не обязателен
реалистичный рендеринг. Рендеринг глобуса должен подчеркивать важность
данных и служить их лучшему восприятию. Для этого существуют варинаты:
растяжение по высоте, вариант с отключенными текстурами, вариант с
программной раскраской глобуса.
Растяжение по высоте
В режиме растяжения по высоте высота каждой точки рельефа
увеличивается в заданное количество раз (рис. 2.1). Увеличенная высота вершин
может сразу учитываться при генерации геометрии, но этот вариант не позволяет
динамически менять высоту и выбирать удобное для работы значение
мультипликатора высоты.
Поэтому более гибкий подход — выполнять растяжение в вершинном
шейдере. Но для этого необходимо знать высоту вершины над эллипсоидом.
Вершины полигональной поверхности хранятся в декартовой системе координат.
Динамическое вычисление высоты вершины довольно сложное и сильно влияет
на производительность. Поэтому высоту каждой вершины проще вычислить
40
заранее и хранить как вершинный атрибут вместе с другими вершинными
атрибутами на видеокарте [43].
На современных видеокартах каждый вершинный атрибут — это 4х-
компонентный вектор. Высота вершины хранится только в 1й компоненте. В
других 3-х компонентах можно передавать в шейдер любые данные о вершине.
Например, нормаль к эллипсоиду в этой точке. Это позволит более точно
растягивать рельеф.
Рис. 2.1. Режим растяжения по высоте в 10 раз
Затенение глобуса
В режиме отключенных текстур показывается эллипсоид в оттенках серого
(рис. 2.2). С помощью затенения подчеркиваются неровности рельефа. Это
удобно в ситуациях, когда текстура имеет более низкое разрешение и мешает
сопоставлению визуализируемых данных с рельефом.
В этом режиме реалистичное освещение не требуется. Для лучшего
подчеркивания деталей рельефа можно использовать традиционный подход с
диффузным освещением по модели Ламберта [71] и бликовым освещением по
модели Блинна-Фонга [72]. Источник света можно двигать вместе с камерой.
Модель Ламберта для диффузного освещения:
, (2.1)
41
где I — освещенность в точке рельефа, — нормаль к поверхности, —
направление на источник света.
Модель Блинна-Фонга для бликового освещения:
, (2.2)
(2.3)
где – вектор направления на наблюдателя, p – коэффициент блеска.
Для интерполяции освещения по поверхности можно использовать модель
Фонга, при которой интенсивность освещения вычисляется для каждого пикселя с
использованием интерполированной нормали. Нормаль интерполируется между
вершинами полигональной сетки.
Чтобы дальше увеличивать качество визуализации, необходимо либо
увеличивать плотность вершин, либо применять карту нормалей. При вычислении
цвета пикселя нормаль берется из карты нормалей. Карта нормалей подходит для
всех уровней детализации, кроме максимального. Она позволяет использовать
нормали со следующего уровня детализации без необходимости увеличения числа
полигонов. Карту нормалей для каждого тайла можно сгенерировать заранее, но
это требует увеличенного времени предобработки.
Условное раскрашивание глобуса
В режиме условного раскрашивания вместо использования текстуры цвет
каждого пикселя рельефа вычисляется в шейдере на основе заданного алгоритма.
Варианты могут быть самые разные в зависимости от задачи, от области
применения глобуса. Самые простые: это раскрашивание по высоте (рис. 2.3) или
раскрашивание в зависимости от нормали рельефа (рис. 2.4). На рельеф вместо
спутниковых снимков можно накладывать изображения с научными данными,
например с сайта NASA [73].
42
Рис. 2.2. Режим отключенных текстур
Описанные режимы могут произвольно комбинироваться. Все режимы
реализуются на уровне вершинного или фрагментного шейдеров рельефа. В
зависимости от выбранных режимов можно динамически генерировать текст
шейдера, компилировать и использовать для визуализации глобуса.
Рис. 2.3. Режим раскрашивания по высоте
Шейдеры в своей работе используют следующие параметры:
вершинные атрибуты: нормаль к рельефу в мировой системе координат,
высоту вершины над эллипсоидом, геодезическую нормаль к эллипсоиду;
uniform-переменные: степень прозрачности рельефа, степень растяжения
по высоте, положение источника света в мировой системе координат, настройки
атмосферы;
дополнительная текстура с картой нормалей;
дополнительная текстура с изображением ночной Земли (огни городов);
43
прочие текстуры, которые можно использовать при визузализации.
Рис. 2.4. Режим раскрашивания по крутизне
2.1.2. Реалистичное отображение глобуса
Очевидное применение реалистичного рендеринга – это компьютерные
игры. Однако такой рендеринг может быть также использован в других областях:
при планировании городов, архитектурном проектировании, при реконструкции
памятников природного наследия, создании тренажеров и симуляторов.
Для реалистичного рендеринга виртуального глобуса необходимо
дополнительно реализовать несколько эффектов.
Атмосферное рассеяние. Чтобы добавить атмосферу к глобусу, нужно
создать сферу вокруг глобуса с режимом отбрасывания лицевых граней, чтобы
всегда была видна только задняя половина сферы. К этой сфере нужно применить
шейдер для расчета эффекта атмосферного рассеяния в зависимости от положения
наблюдателя и положения Солнца. Подробнее это рассмотрено ниже.
Облака. Чтобы добавить вид облаков из космоса, достаточно сделать сферу
вокруг глобуса с готовой полупрозрачной текстурой облаков. Но у поверхности
земли они будут выглядеть размыто. Поэтому по мере приближения к
поверхности глобальные облака можно заменять на процедурно сгенерированные
с помощью шума Перлина, либо на объемные облака [77, 78].
Освещение. Для расчета освещения необходимо учитывать атмосферное
рассеяние, которое рассматривалось выше, и отражательную способность разных
44
территорий. Существуют карты альбедо, которые содержат коэффициент
отражения от 0.0 до 0.9. Дополнительно для водных территорий необходимо
учесть бликовое освещение [79]. Для этого требуется текстура с маской для
различения, где находится вода, а где земля.
Смена времен года. Зная границу снегов зимой можно смоделировать
изменение текстуры северных территорий в зависимости от времени года. Для
задания граны снегов нужна текстура с маской.
Тени. Тени — одна из самых сложных задач, особенно в случае глобуса.
При использовании теневых карт (shadow map) тени получаются размытые из-за
недостаточного разрешения теневой карты [80]. Сложность — в определении
границ видимой территории, на которую нужно накладывать теневую карту.
Увеличение детализации территорий. Современные карты высот,
которые находятся в свободном доступе, имеют низкое разрешение. Чтобы
увеличить детализацию, можно добавить высокочастотный шум к рельфу [81].
2.1.3. Атмосферное рассеяние
Атмосферное рассеяние — это основа реалистичного восприятия
окружающей среды. Задача учета атмосферного рассеяния состоит в вычислении
цвета каждого пикселя неба и поверхности рельефа с учетом положений Солнца и
виртуальной камеры [74].
Луч света, попадая на частицы атмосферы, отклоняется в сторону. Это
описывается коэффициентом рассеяния и фазовой функцией. Ослабление луча
света длиной волны , который проходит путь описывается следующей
формулой, в которой используется оптический путь:
(2.4)
где h — высота, — длина волны, – коэффициент зависимости от длины
волны, NR = 8км — толщина атмосферы с однородной плотностью.
45
Для расчета цвета необходимо вычислить, какая часть изначального пучка
света от Солнца рассеялась, а какая осталась и попала на сетчатку глаза. Это
определяется уравнением рассеяния. В это уравнение входит громоздкий
интеграл, который аналитически не берется, а численное интегрирование
довольно сложное. В 1993 году Нишита предложил алгоритм расчета интеграла,
который, однако, занимал много времени [74].
Проведение этих расчётов в реальном времени долго было недостижимой
задачей. В начале 2000-х годов с появлением графических процессоров и
возможности их программирования с помощью языков шейдеров начались
разработки по расчёту цвета атмосферы в реальном времени. В 2005 году О’Нил
упростил алгоритм Нишиты и адаптировал его для расчета на GPU [75]. Алгоритм
подходит для бесшовного рендеринга атмосферы для любого положения камеры
от поверхности до дальнего космоса и любого вектора направления на Солнце.
Многие авторы в дальнейшем занимались усовершенствованием этого алгоритма
[40, 76].
Несмотря на сильное упрощение, алгоритм обеспечивает правдоподобный
результат. Из-за его простоты и высокого быстродействия он сейчас используется
во многих графических приложениях.
Для сравнения в работе [40] дополнительно используются текстуры с
предрассчитанными значениями. В работе [76] дополнительно производится учет
множественного рассеяния и учет неровностей рельефа.
Технически алгоритм распадается на две составные части: вычисление
цвета неба и модификация цвета рельефа.
Для рендеринга неба используется сфера с радиусом на 2,5% больше
полярного радиуса Земли с включенным отбрасыванием лицевых граней
полигонов, чтобы наблюдатель видел только изнанку сферу. Большая часть сферы
закрывается земным эллипсоидом. Через каждый пиксель неба пускается луч, и
определяются точки входа и выхода из атмосферы. Для полученного отрезка
вычисляется интеграл рассеяния методом численного интегрирования. Отрезок
разбивается на несколько точек, для которых вычисляется доля рассеянного света
46
(рис. 2.5). Интеграл считается для 3-х компонент света и для 2-х случаев
рассеяния. Результат суммируется.
Рис. 2.5. Атмосферное рассеяние
Аналогичный алгоритм можно применить и для рельефа. Отраженный от
рельефа луч свет также претерпевает рассеяния в атмосфере. Чем дальше
находится точка рельефа, тем сильнее свет рассеивается. Поэтому дальние
участки рельефа у горизонта кажутся находящимися в голубоватой дымке. Цвет
неба плавно переходи в цвет поверхности (рис. 2.6).
Рис. 2.6. Атмосфера
Эту же идею можно применить к рендерингу объектов на рельефе,
например, удаленных деревьев и домов, которые также скрываются в голубоватой
дымке.
2.2. Полупрозрачная поверхность глобуса
Была поставлена задача: разработать способ визуализации глобуса с
полупрозрачной поверхностью с возможностью как надземного, так и подземного
просмотра.
47
Традиционно при визуализации объектов под поверхностью рельефа не
используется виртуальный глобус. Показывается изолированный участок рельефа,
его можно «облететь» со всех сторон, можно посмотреть сбоку или сделать
сечение (рис. 2.7).
Поэтому визуализация объектов под поверхностью глобуса — новая задача,
и здесь необходимо разработать новый подход. Очевидная идея — сделать
поверхность рельефа полупрозрачной. Однако при простом включении
прозрачности возникает ряд графических артефактов (рис. 2.8, 2.9, 2.10).
2.2.1. Анализ проблемы
Рассмотрим в деталях традиционный подход к рендерингу трехмерной
сцены с виртуальным глобусом с включеной полупрозрачностью, основанный на
спецификации OpenGL [71]. Вначале рендерятся непрозрачные подземные
объекты. Далее рендерится рельеф. Для каждого фрагмента рельефа вычисляется
цвет RGB на основе текстуры и с учетом освещения и задается значение
прозрачности А (альфа-канал). Если фрагмент прошел тест глубины, то его цвет
смешивается с цветом пикселя в буфере цвета, который принадлежит подземному
объекту.
Спецификация OpenGL определяет несколько формул для смешивания.
Наиболее часто используется следующая:
, (2.5)
где — цвет входящего фрагмента, — цвет пикселя в буфере цвета,
— значение прозрачности входящего фрагмента. Итоговый цвет
записывается в буфер цвета.
48
Рис. 2.7. Объект под рельефом
В случае виртуального глобуса это приводит к следующим эффектам.
Если подземные объекты не локализованы в одной точке, а распределены по
всему глобусу, то объекты у дальней поверхности глобуса становятся видны
наравне с объектами у ближней поверхности глобуса (рис. 2.8). Это приводит к
визуальной «каше» и путанице.
Рис. 2.8. Просвечивают дальние объекты
Если используется атмосфера, то она обычно рендерится до глобуса.
Поэтому при включении прозрачности атмосфера также начинает просвечивать
сквозь рельеф. В зависимости от алгоритма визуальный эффект может быть
разным. Например, как на рис. 2.9.
49
Рис. 2.9. Просвечивает атмосфера
Рис. 2.10. Просвечивают горы
«Юбки» тайлов также начинают просвечивать. Изображение на экране
становится чувствительном к порядку отрисовки тайлов и к повороту камеры
относительно тайла: при определенных углах поворота камеры сквозь гористые
участки рельефа начинают просвечивать другие части рельефа (рис. 2.10).
Часть этих эффектов может быть сравнительно легко устранена, но при
этом могут возникнуть новые графические артефакты. Например, «юбки» тайлов
можно вообще отключить. Но тогда станут видны щели между тайлами. Или
атмосферу можно рендерить после глобуса, а не до. Но тогда придется сильно
разносить ближнюю и дальнюю плоскости отсечения объема видимости. Это
приведет к падению точности буфера глубины, а следовательно к эффекту
мерцания (z-fighting).
50
Существуют универстальные алгоритмы корректного учета прозрачности,
основанные рендеринге в несколько проходов, такие как depth peeling [82] или
depth partition. Однако они устраняют не все графические артефакты.
В целом традиционный подход можно изобразить на рисунке 2.11.
Рис. 2.11. Традиционный порядок рендеринга
Поэтому необходим новый способ качественного рендеринга
полупрозрачного рельефа виртуального глобуса. Этот способ должен
удовлетворять следующим условиям:
не должны просвечивать объекты с дальней стороны глобуса;
одни элементы рельефа не должны просвечивать сквозь другие;
способ не должен влиять на рендеринг самих подземных объектов (не
должен требовать изменения алгоритма рендеринга подземных объектов);
атмосфера, а также другие космические объекты (Солнце, Луна, звезды)
не должны просвечивать через глобус;
рендеринг атмосферы не должен приводить к большому разбросу
ближней и дальней плоскостей отсечения.
51
Кратко поясним последний пункт. Глубина пикселя вычисляется на основе
ближней и дальней плоскостей отсечения объема видимости и приводится к
диапазону [-1; 1]. В OpenGL используется следующая формула [69, 83]:
(2.6)
где n — расстояние от камеры до ближней плоскости отсечения, f — расстояние
до дальней плоскости отсечения z — расстояние до искомого пикселя. График
зависимости глубины от расстояния изображен на рисунке 2.12.
Видно, что разрешение буфера глубины падает с удалением от камеры.
Половина диапазона значений буфера приходится на область вблизи ближней
плоскости отсечения.
Это приводит к тому, что для двух далеких полигонов становится
невозможным корректное сравнение глубин. Возникает мерцание, которое
называется z-fighting: на одном кадре может быть виден пиксель одного полигона,
а на следующем кадре — пиксель другого полигона.
Рис. 2.12. Зависимость глубины от расстояния до камеры
Это проблема возникает в любых приложениях с 3D графикой [84].
Чтобы избежать такой «борьбы», рекомендуется разброс f-n делать как
можно меньше. При просмотре глобуса с атмосферой из космоса значения f и n
будут определятся самим глобусом. Но при приближении камеры к поверхности
на значение f будет оказывать сильное влияние атмосфера.
52
2.2.2. Предлагаемый способ
Предлагается способ визуализации глобуса, который устраняет графические
артефакты с помощью двухпроходного рендеринга:
1. Вначале рендерится концентрическая сфера внутри глобуса с радиусом
R и цветом C. Использование сферы позволяет скрыть подземные объекты с
дальней стороны глобуса. Цвет сферы можно выбрать под цвет фона, например,
черный. Радиус выбирается в зависимости от подземных объектов, которые
нужно показать или скрыть. Для большинства задач подходит км,
где — экваториальный радиус Земли. 1000км выбрано, потому что самые
глубокие землетрясения были зарегистрированы на глубние 700км.
Для разных подземных объектов можно придумать собственные алгоритмы
для контроля видимости. Можно скрывать объекты по расстоянию от камеры.
Можно скрывать объекты с учетом горизонта [85]. Но концентрическая сфера
внутри глобуса — один из самых простых и универсальных способов.
2. Далее рендерятся сами подземные объекты обычным способом.
Объекты с противоположной стороны глобуса не проходят тест глубины и
отбрасываются.
3. Далее в 2 прохода рендерится рельеф. При первом проходе отключается
запись в буфер цвета, и происходит заполнение буфера глубины. Значение в
буфере глубины для каждого пикселя соответствует ближайшему к камере
фрагменту рельефа.
4. При втором проходе происходит запись в буфер цвета при условии
совпадения глубины фрагмента со значением в буфере глубины. Это гарантирует,
что в буфер цвета попадут только ближайшие к камере фрагменты рельефа. Перед
записью в буфер цвета происходит смешивание цветов с уже имеющимися там
значениями, которые относятся к подземным объектам.
5. Далее необходимо рендерить звезды, Солнце, Луну и атмосферу. Если
включить тест глубины для проверки перекрытия с глобусом, то сильно
увеличится разброс между дальней и ближней плоскостями отсечения. Поэтому
53
необходимо использовать буфер трафарета (stencil buffer) [71]. Буфер трафарета
позволяет записывать туда значения при наступлении определенных условий, а
также выполнять тест трафарета перед записью цвета в буфер цвета.
Буфер трафарета позволяет сформировать маску рельефа во время второго
прохода рендеринга рельефа. Для этого в буфер производится запись значения 1.
Тест трафарета для рельефа не производится.
Далее рендерятся звезды, Солнце, Луна и атмосфера. Они рендерятся по
очереди в указанном порядке, но общая логика рендеринга одинакова. Тест
глубины отключается. Вместо этого включется тест трафарета. Цвет фрагмента
атмосферы записывается в буфер цвета только при условии, что значение в
буфере трафарета не равно 1. Значение в буфере не изменяется.
6. Наконец, последними рендерятся надземные объекты. Здесь
существенно, что это происходит после атмосферы, т.к цвет полупрозрачных
поверхностей (деревья, частицы) должен смешиваться с цветом атмосферы.
Вся последовательность шагов изображена на рисунке 2.13.
При использовании черезстрочного стерео для создания стереоэффекта
также используется буфер трафарета. Необходимо это учесть при реализации
алгоритма, чтобы не было конфликтов между ними.
Отдельно встает задача выбора формулы смешивания цвета подземных
объектов и цвета рельефа. Использование формулы (2.5) приводит к следующему:
при выставлении значения альфа-канала в 1 (непрозрачность) подземные
объекты становятся не видны;
при выставлении значения альфа-канала в 0 (полная прозрачность)
рельеф становится не виден. Это затрудняет управление виртуальной камерой;
при выставлении промежуточных значений блекнут цвета и рельефа, и
подземных объектов. Яркость цветов подземных объектов уменьшается. Это
ухудшает визуальное восприятие.
54
Рис. 2.13. Порядок рендеринга для полупрозрачного рельефа
Предлагается использовать немного другую формулу:
, (2.7)
При этом цвет подземного объекта складывается с цветом рельефа,
уменьшенным с помощью значения альфа-канала. Цвета становятся более
яркими, но в некоторых случаях возможна «засветка». Необходимо дать
пользователю возможно через интерфейс пользователя регулировать значение
прозрачности для настройки удобных для восприятия цветов.
Рассмотрим плюсы и минусы предложенного алгоритма. Минусы:
необходимость рендерить рельеф 2 раза и необходимость выделения памяти для
буфера трафарета. Это приводит снижению производительности приложения.
Плюсы: отсутствуют графические артефакты, упомянутые в начале параграфа.
Существует также альтернативный способ обхода проблемы с
атмосферой, основанный на логарифмическом буфере глубины [69]. Идея
55
следующая: вместо формулы (2.6) использовать логарифм для вычисления
глубины в зависимости от расстояния до камеры:
, (2.8)
где C — калибровочный параметр.
Это полностью решает проблему точности буфера глубины и устраняет
мерцание (z-fighting), что позволяет спокойно рендерить атмосферу в общем
пространстве с глобусом с включенным тестом глубины без применения буфера
трафарета.
Однако у такого подхода есть недостатки. Реализация формулы (2.8)
возможна только на уровне шейдеров, а значит пропадает возможность
использования фиксированного графического конвейера для отдельных объектов.
Более того: вычисление логарифмической глубины необходимо внести в шейдеры
для всех объектов трехмерной сцены, что противоречит одному из требований
сформулированных выше. Также это повышает вычислительную нагрузку на
видеокарту, что приводит к дальнейшему уменьшению производительности.
2.2.3. Вариант с камерой под поверхностью
Рассмотрим режим, когда камера находится под поверхностью земли. Этот
режим нужен, чтобы иметь возможность рассмотреть подземный объект со всех
сторон, а не только сверху, и без искажений цветов, которые создает
полупрозрачная поверхность рельефа.
Существующие алгоритмы рендеринга рельефа рассчитаны, что просмотр
будет осуществляться сверху. Поэтому под рельеф убирают вспомогательную
геометрию — «юбки» тайлов, отключают рендеринг обратных граней полигонов.
Алгоритм определения видимости тайлов зависит от положения камеры над
поверхностью. Пример получающихся графических артефактов изображен на
рисунке 2.14.
56
Рис. 2.14. Графические артефакты при спуске под поверхность рельефа
Поэтому при спуске камеры под землю необходимо изменить параметры
визуализации базового алгоритма, а именно: переключение режима отбрасывания
граней с обратных на лицевые, отключение рендеринга юбок тайлов и атмосферы.
Это обеспечивает минимально приемлемый подземный вид (рис. 2.15). Для
примера на рисунке изображен подземный объект — 3D-модель канала гейзера.
Традиционный подход к рендерингу рельефа предполагает отбрасывание
тайлов, когда они выходят за линию горизонта [86]. Базовая идея алгоритма
основана на формуле:
(2.9)
где — усредненная нормаль тайла, — центр тайла, — положение
камеры. Если , то тайл находится за линией горизонта. Для гористых
районов эта формула напрямую не подходит, т.к. вершины гор могут быть видны
из-за горизонта. Поэтому применяют более сложные вариации этой формулы.
Однако при спуске под землю такая проверка приводит к тому, что виден
лишь небольшой участок рельефа вблизи камеры (рис. 2.15). При отключении
проверки на выход тайлов за горизонт становится видна изнанка глобуса (рис.
2.16). Но при этом возникает другая проблема: мерцание отдаленных тайлов (z-
fighting) из-за большого разброса значений ближней и дальней плоскостей
57
отсечения. По мере спуска дальше под землю ближняя плоскость отсечения
отодвигается и эффект мерцания пропадает.
Рис. 2.15. Вид из под земли
Выбор между двумя вариантами не является очевидным и зависит от
конкретной задачи. Если под землей нужно рассмотреть отдельный объект, то
дальние тайлы просто не нужны, и проверку на выход за горизонт можно
оставить. Если же рассматривается протяженный объект или множество объектов
(например, каталог землетрясений), то проверку на выход за горизонт нужно
отключить, а с мерцанием бороться разными способами (например, с помощью
логарифмического буфера глубины, который упоминался выше).
Следующий спорный момент — это прозрачность поверхности. Здесь
возможны три альтернативы:
сделать рельеф полностью непрозрачным. Тогда будут видны только
подземные объекты;
сделать рельеф прозрачным для всех объектов. Можно будет из-под
земли видеть надземные объекты: дома, машины, деревья;
сделать рельеф прозрачным только для некоторых объектов: например,
которые частично находятся под землей, частично над землей.
Первый вариант - это традиционный рендеринг в один проход с учетом
модификаций, описанных в начале этого параграфа. Второй и третий вариант
требуют 2х-проходного рендеринга, аналогичного описанному в предыдущем
58
параграфе. При этом необходимо только изменить порядок рендеринга: сначала
надземные объекты, потом подземные объекты, затем рельеф. Пример со
зданиями показан на рисунке 2.17.
Рис. 2.16. Вид из-под земли с отключенной проверкой на выход тайлов за горизонт
Рис. 2.17. Вид из под земли на надземные объекты
Выбор конкретного варианта должен осуществляться в каждом проекте
индивидуально и зависит от поставленных задач.
2.3. Применимость для подземных объектов
Подземные объекты могут иметь разную природу и визуализироваться с
разными целями. Рассмотрим, какие бывают типы подземных объектов, и
применимость к ним предложенного способа визуализации глобуса.
59
1. Облака точек. Это могут быть очаги землетрясений или результаты
точечных бурений для изучения свойств земли. Точки хорошо сочетаются с
предложенным способом. Они практически не оказывают влияния друг на друга
(не «загораживают» другие точки). Облако целиком можно рассмотреть с разных
ракурсов или путем перемещения камеры внутри облака. Подробнее визуализация
облаков точек рассмотрена в параграфе 3.1.
2. Отдельные объекты: искусственные (шахты, скважины, тоннели) или
природные (пещеры, разломы). Они могут быть заданы в виде своих
ограничивающих поверхностей и визуализироваться как самые обычные
полигональные поверхности (рис. 2.15). Для подчеркивания формы объекта
необходимо применять освещение. Но поскольку солнечное освещение под
землей не действует, то рекомендуется совместить источник света с виртуальной
камерой.
3. Объемные данные — трехмерная матрица значений. Они могут быть
получены методом сейсмотомографии или интерполяцией других данных. В
параграфе 3.2 предложен алгоритм рендеринга таких данных на глобусе,
основанный на прямом объемном рендеринге. При этом доступны все
возможности прямого объемного рендеринга: выделение изоповерхностей,
назначение прозрачности и цвета в зависимости от значения параметра в ячейке.
4. Слоистые протяженные данные — геологические слои, водоносные
горизонты, почвы. Для таких объектов предложенный способ с полупрозрачной
поверхностью глобус применим плохо. Под полупрозрачной поверхностью будет
располагаться другая поверхность, скрывающая всё остальное.
Возможные варианты решения для слоистых данных:
регулировка коэффициента полупрозрачности для каждого слоя в
отдельности;
«вырез» участка данных и участка рельефа для просмотра среза слоев.
Здесь необходимо разработать алгоритм динамического перемещения выреза
глобуса и динамического контроля его размеров, чтобы обеспечить удобную
работу с данными.
60
Также полезна возможность залететь под землю и просмотр подземных
объектов вблизи. В случае слоистых данных перед виртуальной камерой может
быть фиксирована плоскость среза, которая движется вместе с камерой.
2.4. Выводы по 2 главе
В главе рассмотрены основные способы и варианты визуализации глобуса,
предложен новый способ визуализации глобуса, сделаны следующие выводы:
1. В зависимости от потребностей отрасли науки, в которой используется
виртуальный глобус, рельеф можно отображать на экране по-разному:
модифицировать саму геометрию (растяжение по высоте), раскрашивать с
помощью палитры цветов (по высоте, по крутизне склона рельефа и т.д.),
смешивать несколько текстур, модифицировать цвет текстуры (учитывать
освещение, атмосферное рассеяние).
В геофизике и геологии существует необходимость просмотра подземных
объектов и 3D-данных. Визуализация таких данных на глобусе — является новой
задачей. Если включить полупрозрачность для поверхности глобуса, то при
традиционном подходе возникает ряд графических артефактов.
2. Предлагается способ визуализации полупрозрачной поверхности глобуса,
при котором эти артефакты отсутствуют. В предложенном способе рельеф
отрисовывается в два прохода. При рендеринге атмосферы используется маска в
буфере трафарета.
Дополнительно рассматривается случай, когда виртуальная камера
находится под поверхностью рельефа. В этом случае предложенный способ также
работает, но с рядом модификаций.
3. Разработанный способ визуализации позволяет просматривать и
визуально анализировать подземные 3D-данные: очаги землетрясений, подземные
структуры, скважины, слои и т.д. Способ позволяет просматривать данные как
сверху, сквозь поверхность рельефа, так и из-под земли.
61
ГЛАВА 3. Визуализация данных на виртуальном глобусе
3.1. Облака точек
3.1.1. Обзор современного состояния дел
Облака точек — один из самых простых типов данных. Необходимость
визуализации таких данных на виртуальном глобусе возникает в разных областях,
однако при этом возникает ряд технических сложностей.
Один из примеров точек на глобусе — это гипоцентры землетрясений,
которые хранятся в виде каталогов. Гипоцентр — это центральная точка очага
землетрясения, которая находится в глубине земли. Проекция гипоцентра на
поверхность Земли называется эпицентром. Каталоги гипоцентров свободно
доступны на специализированных сайтах, например, на сайте Геологической
службы США (USGS) [87], на сайте Камчатского филиала Геофизической службы
РАН [88], и др. Каталог землетрясений для всей Земли с 1900 года включает
около 1 млн. событий.
Точки из каталогов могут покрывать большие территории, возможно даже
всю поверхность глобуса, и могут иметь разные высоты и глубины. Такие точки
изначально хранятся в географической системе координат, и перед визуализацией
их необходимо переводиться в мировую декартову систему координат.
Другой пример источника облаков точек — лазерное сканирование.
Лазерное сканирование — это современный способ для быстрого создания
высокоточных 3D-моделей зданий и любых объектов в виде облаков точек [89].
Точность может достигать 1 мм. Сначала производится сканирование объекта с
разных позицией, затем — обработка полученых исходных облаков точек.
Процесс обработки состоит из 2х этапов: сначала все облака для одного объекта
сшиваются в единое облако точек (рис. 3.1), затем по этому облаку точек
восстанавливается полигональная 3D-модель. Первый этап проходит быстро и
может быть автоматизирован. Однаков второй этап довольно трудоёмкий, требует
ручной работы и может затянуться на месяцы.
62
Рис. 3.1. Облако точек Шуховской башни
Поэтому вместо того, чтобы создавать полигональную 3D-модель объекта,
можно работать с точечной 3D-моделью. Облако точек для одного здания может
содержать 50-100 миллионов точек и занимать в памяти несколько гигабайт. Это
делает невозможным интерактивный рендеринг полного облака точек.
Необходимо использовать уровни детализации.
Исследования в области обработки и визуализации облаков точек ведутся
много лет. Значительные усилия тратятся на развитие методов и разработку
библиотек для реконструкции полигональных поверхностей по облакам точек
[90].
Кроме того, существуют методы визуализации непосредственно самих
облаков точек. Обзор таких методов дан в статье [91]. Они различаются как
разбиением облака точек на уровни детализации, так и способами рендеринга
самих точек. Существуют три основных способа:
визуализация облаков точек в виде простого точечного примитива
OpenGL (GL_POINT). Они изображаются на экране в виде либо квадрата, либо
окружности заданного размера. В вершинном шейдере можно задавать размер
индивидуально для каждой вершины;
визуализация облаков точек в виде спрайта — четырехугольника,
который всегда повернут к камере. Это более медленный, но более гибкий
вариант, т.к. позволяет использовать текстуру с прозрачностью;
63
визуализация в виде одного или нескольких треугольников фиксировано
расположенных в пространстве, перпендикулярно вектору нормали. Они
называются splats («нашлепки»). Это самый медленный, но наиболее гибкий
вариант, который обеспечивает лучшее визуальное качество.
Спрайты и треугольники — это попытка скрыть промежутки между
точками, чтобы 3D-модель визуально выглядела целостной, без дыр [92, 93]. Есть
и другие подходы к этой проблеме, основанные на постпроцессинге [94].
Поскольку размеры облаков точек растут, то появляются методы по их
сжатому хранению и распаковке на видеокарте [95, 96].
Для более качественно рендеринга с освещением необходимо знать нормаль
в каждой точке. Если нормали изначально не заданы, то их можно вычислить.
Существуют методы для этого [97].
В работе [46] предлагается отказаться от построения полигональных
моделей зданий и использовать облака точек для создания 3D-моделей целых
городов.
В моно-режиме облака точек сложно воспринимать на экране из-за
отсутствия ощущения глубины точек. Все точки кажутся расположенными на
одном расстоянии и сливаются в «кашу», особенно если используются не
реальные, а условные цвета. Но ситуация меняется в случае использования
стереоскопической визуализации. Визуально можно легко отделить точки,
расположенные ближе, от точек, расположенных дальше. Это превращает
стереовизуализацию в мощный инструмент для визуального анализа научных
данных. Именно поэтому в данной работе делается акцент на точечных данных.
Точки удобны тем, что они рендерятся очень быстро, т.к. это базовый
геометрический примитив. Современные видеокарты позволяют рендерить около
10 миллионов точек каждый кадр с интерактивной частотой кадров. Поэтому нет
необходимости проверять индивидуальные точки на попадание в объем
видимости.
На вызов каждой операции отрисовки тратится небольшой время
(накладные расходы). Чтобы минимизировать суммарное время, рекомендуется
64
объединять точки из разных облаков в единый массив, для отрисовки одной
командой.
С другой стороны, если точки распределны по большой территории, то
имеет смысл разбить все точки на несколько частей по пространственному
признаку и проверять каждый кусок на попадание в область видимости.
Необходимо динамически определять, какие точки показывать в
зависимости от положения виртуальной камеры. При приближении камеры
необходимо показывать дополнительные точки в той части модели, которая
попадает в область видимости камеры. А при отдалении снова скрывать их.
3.1.2. Алгоритм визуализации облаков точек
Была поставлена задача разработать алгоритм для интерактивного
рендеринга больших облаков точек (размером больше 100 млн. точек) на
виртуальном глобусе и динамической фильтрации их по заданным параметрам.
Можно заметить, что при разрешении 1920х1080 максимальное число
видимых точек на экране составляет около 2 млн. Поэтому при просмотре облака
с большого расстояния нет необходимости отображать все 100 млн. точек
целиком.
В основе предложенного алгоритма лежит подход с дискретными уровнями
детализации, при котором облако разбивается на фрагменты — мини-облака.
Когда камера находится далеко, то показывается один фрагмент, который
содержит точки случайным образом выбранные из полного облака точек. По мере
приближения камеры должны показываться фрагменты более высоких уровней
детализации. Все фрагменты должны содержать примерно одинаковое количество
точек, но на более высоких уровнях детализации пространственный размер
фрагмента должен быть меньше и фрагментов должно быть больше.
Идеологически эта схема напоминает подход с тайлами рельефа, описанный
в параграфе 1.3.4. Однако природа точечных данных позволяет сделать одно
существенное усовершенствование. В случае рельефа при приближении тайлы
более высоких уровней детализации заменяют тайлы низких уровней
65
детализации. Но точечные данные разных уровней детализации могут не мешать
друг другу. Точки нескольких уровней детализации можно показывать
одновременно. При приближении камеры фрагменты низкого уровня детализации
не должны скрываться, а фрагменты более высоких уровней детализации должны
добавляться к существующим.
Такой подход позволяет не дублировать точки между уровнями
детализации. В памяти облако точек, разбитое на уровни детализации, будет
заниматься столько же места, сколько и целое.
Генерация дерева фрагментов
В начале необходимо сгенерировать дерево фрагментов: разбить всё облако
точек на фрагменты и расчитать расстояние видимости для каждого фрагмента.
Алгоритм основан на рекурсивном разбиении пространства и хранении
данных в древовидной структуре данных. Древовидная структура данных
включает квадро- и октодеревья. В случае квадродерева вся область рекурсивно
разбивается на 4 ячейки. В случае октодерева — на 8 ячеек (рис. 3.2).
Рис. 3.2. Схема октодерева
Далее перечислены шаги алгоритма.
0. Предварительный этап. Если облаков точек несколько, то их всех
необходимо объединить в единое облако, и преобразовать координаты из
локальных систем координат в географическую систему координат.
66
1. Построение корневого ограничивающего бокса. На этом шаге
перебираются все точки полного облака точек для определения минимальных и
максимальных значений координат по 3м осям. Далее вычисляются координаты
вершин ограничивающего бокса, который плотно содержит в себе полное облако
точек.
2. Начальное построение дерева. Каждый узел дерева имеет следующие
атрибуты: соответствующий этому узлу ограничивающий бокс, массив вершин
этого узла, массив цветов (и возможно массивы интенсивностей и других
вершинных атрибутов) и ссылки на дочерние узлы.
Построенный на первом шаге бокс используется для создания корневого
узла дерева.
На этом шаге происходит последовательное чтение точек (из файла или
другого источника данных для облака точек) и помещение их в корневой узел
дерева с помощью метода добавитьТочку() (рис. 3.3).
В методе добавитьТочку() происходит помещение точки в локальный
массив вершин этого узла до тех пор, пока их количество не превысит значение
параметра .
Если количество точек превысило то происходит разбиение
ограничивающего бокса и построение соответствующих дочерних подузлов. Все
имеющиеся в данном узле точки распределяются по дочерним узлам, вызывая
метод добавитьТочку() у каждого из дочерних подузлов.
При последующих вызовах добавитьТочку() происходит рекурсивный
вызов добавитьТочку() у дочерних узлов. Когда количество точек в некотором
узле достигнет значения , то процедура разбиения повторяется.
Вначале разбиение прозводится на 4 подбокса путем разрезания исходного
по середине по долготе и широте. Далее квадродерево переходит в октодерево —
дополнительно производится разрезание по средней высоте.
67
В конце этого этапа, когда все точки из полного облака будут обработаны,
получится древовидная структура. Точки будут распределены по листовым узлам
этого дерева.
Рис. 3.3. Распределение вершин по узлам
3. Перераспределение точек в дереве. В начале этого этапа все точки
распределены по узлам максимального уровня детализации M. Теперь нужно
заполнить точками другие уровни детализации. При этом точки не должны
дублироваться, т.е. точки будут браться из дочерних узлов и подниматься вверх в
иерархии.
Рекурсивно для всех промежуточных узлов, начиная с узлов уровня
детализации М-1 и вверх по дереву должна быть выполнена следующая операция.
Случайным образом из всех дочерних узлов нужно отобрать точек и поместить
в массив вершин данного узла. , поэтому эта операция всегда возможна.
Далее перебираются все дочерние узлы. Если в каком-то из них осталось меньше
точек, то они все переходят в массив вершин данного узла.
68
В результате этого этапа корневой узел будет содержать точек, каждый
промежуточный узел будет содержать не меньше и не больше
точек, а листовые узлы не меньше и не больше .
4. Генерация геометрии. На основе каждого узла дерева создается объект,
который будет отвечать за визуализацию данного фрагмента облака точек.
При визуализации глобального облака точек возможна следующая
ситуация: при попытке приблизиться к точке или к группе рядом стоящих точек
возникает дрожание (jittering). Как упоминалось в параграфе 1.3.4, это связано с
использованием типа данных с одинарной точностью (float). Числа с плавающей
точкой имеют фиксированную относительную точность, но изменяющуюся
абсолютную точность. Точность обратно пропорциональная расстоянию от
начала координат (центра глобуса). На поверхности глобуса абсолютная точность
составляет около 1м. Чем выше от поверхности, тем ниже точность.
Поэтому координаты всех точек узла преобразуются из географической в
локальную декартову систему координат данного узла.
Разработка приложения велась на основе фреймворка OpenSceneGraph,
поэтому удобно представить результирующую структуру данных с
использованием классов OpenSceneGraph наподобие схемы для тайлов рельефа на
рисункеРис. 1.15.
Конечная геометрия хранится в объектах класса Geode. Класс Group
отвечает за группировку элементов графа сцены, а класс PagedLOD за
переключение видимости в зависимости от расстояния и за подгрузку объектов с
диска.
На рисунке 3.4 представлена часть графа сцены, которая относится к
одному фрагменту облака точек и хранится в одном файле. Этот файл прикреплен
к экземпляру класса PagedLOD. Когда камера приблизится к заданному
расстоянию, то файл будет подгружен с диска в память. На экране отобразится
геометрия данного фрагмента (Geode) и будут задействованы еще 8 экземпляров
69
PagedLOD, который в нужный момент подгрузят дочерние узлы следующего
уровня детализации.
Алгоритм имеет несколько степеней свободы: значение параметров , ,
и расстояние, с которого нужно подгружать данный фрагмент.
Рис. 3.4. Граф сцены
Если параметры , , будут слишком маленькие, то возрастут затраты
времени на накладные расходы видеокарты и на проверку видимости каждого
фрагмента. Если эти параметры будут слишком большие, то новые фрагменты
будут долго подгружаться с диска или интернета, и станут заметны скачки
частоты кадров. Предлагается использоваться следующие значения: ,
, .
5. Вычисление расстояний видимости фрагментов
Необходимо также настроить переключение видимости фрагментов.
Расстояние, с которого нужно подгружать фрагмент, должно определяться,
исходя из визуальной плотности точек на экране в момент подгрузки.
Угловой размер каждого пикселя экрана определяется по следующей
формуле:
(3.1)
70
где sd — расстояние до экрана, sh — высота экрана, — количество пикселей
экрана по высоте.
Для каждого фрагмента строится своя ограничивающая сфера радиуса R. Со
стороны наблюдателя сфера будет казаться диском радиусом R. Если считать, что
все точки распределены по диску равномерно, то угловой размер расстояния
между точками будет равен:
(3.2)
где M — число точек во фрагменте, d— расстояние до центра фрагмента, которое
и нужно найти.
Если теперь положить, чтобы угловое расстояние между точками равнялось
угловому расстоянию между пикселями, мы получим нужное расстояние до
центра фрагмента:
(3.3)
В зависимости от производительности видеокарты и желаемой частоты
кадров можно ввести коэффициент пропорциональности, чтобы уменьшить
визуальную плотность точек.
Вышеописанный алгоритм для работы загружает все облако точек в память.
Однако на 32х-битных системах существует ограничение по памяти в 2Гб.
Поэтому если размер облака точек превосходит 2Гб, то необходимо
предварительно разбить всё облако на несколько частей и применить алгоритм к
каждой части по отдельности.
Визуализация и фильтрация точечных данных
Обычно точки имеют не только координаты, но и визуальные атрибуты
(размер и цвет) и множество дополнительных атрибутов. Например, в случае
71
лазерного сканирования это может быть интенсивность отраженного луча лазера.
В случае гипоцентров землетрясений — магнитуда, время события, регион
принадлежности события [11].
Визуальные атрибуты могут быть заданы изначально, а могут вычисляться
на основе дополнительных атрибутов. Например, если атрибут x изменяется от 0
до 1, то цвет можно вычислить по формуле спектра [98]:
(3.4)
При этом цвет плавно изменяется от синего до красного (рис. 3.5).
Рис. 3.5. Непрерывная палитра цветов
Для размера точек еще проще:
(3.5)
Также часто необходимо осуществлять фильтрацию облака точек по
заданным параметрам. Например, показывать только точки, атрибуты которых
попадают в заданный диапазон.
Вычисление визуальных атрибутов и фильтрацию можно делать на
центральном процессоре. Однако этот процесс занимает время, т.к. выполняется
или последовательно, или в лучшем случае распараллеливается на нескольких
ядрах ЦП. При попытке выполнять такие вычисления в реальном времени для
больших объемов точек произойдет серьезное падение производительности.
Однако современные видеокарты позволяют визуализировать миллионы
точек с интерактивной частотой кадров и производить вычисления в вершинном
шейдере прямо во время рендеринга. Можно динамически изменять цвета точек,
их размер, и производить фильтрацию на основе значений вершинных атрибутов.
72
У разных облаков точек могут быть разные атрибуты. Даже в рамках одного
облака может быть необходимо изменять параметры фильтрации и вычисления
визуальных атрибутов. Для каждого случая нужно иметь свою версию
вершинного шейдера. Чтобы не писать каждый раз шейдер вручную, лучше его
генерировать автоматически.
Рассмотрим весь процесс подробнее.
1. Задание вершинных атрибутов. Спецификация OpenGL позволяет
загружать на видеокарту вершинные атрибуты, которые далее можно
использовать в вершинном шейдере. Каждый атрибут — это 4х-мерный вектор со
значениями типа float [99]. Однако сырые данные могут быть в других форматах:
целочисленный, дробный, булевский, дата-время. Их нужно перевести в тип с
плавающей точкой. Целые числа и булевские переводятся однозначно.
Приведение даты-времени зависит от требуемой точности: дни, секунды или доли
секунды. Например, если все даты относятся к периоду после 1970 года, то можно
использовать Unix-time представление: число секунд, прошедшее с 1го января
1970 года. Если нужно охватить больший период времени, или нужна большая
точность, то дату-время можно превратить в 2 числа с плавающей точкой: одно
описывает номер дня, начиная с заданного момента в прошлом, другое — время в
рамках одного дня.
4 разных атрибута точки можно передать на видеокарту как компоненты 4-
вектора вершинного атрибута.
2. Создание uniform-переменных. Для каждого атрибута создаются
несколько uniform-переменных. 2 переменные задают минимальное и
максимальное значение атрибута. Во время исполнения шейдера проверяется
попадание значения атрибута в выбранный диапазон. Если он не попадает, то
вершина отбрасывается. 2 булевские переменные задают условия: нужно
вычислять цвет точки или размер точки на основе этого атрибута.
3. Генерация тела шейдера. В цикле по всем атрибутам к шапке и к телу
вершинного шейдера добавляются вставки.
Пример, шапки для одного атрибута:
73
attribute vec4 attr1;
uniform float attr1xMin;
uniform float attr1xMax;
uniform bool attr1xColor;
uniform bool attr1xSize;
Пример, тела шейдера для одного атрибута:
if (attr1.x < attr1xMin || attr1.x > attr1xMax)
{
discardPoint = true;
}
else if (attr1xColor)
{
float ratio = (attr1.x - attr1xMin) /
(attr1xMax - attr1xMin);
gl_FrontColor = getColorFromPalette(ratio);
}
else if (attr1xSize)
{
float ratio = (attr1.x - attr1xMin) /
(attr1xMax - attr1xMin);
gl_PointSize = minSize + ratio * (maxSize - minSize);
}
Здесь переменная discardPoint задается один раз на весь шейдер. Также
отдельно определена функция getColorFromPalette на основе формулы (3.4).
Выше приведен пример проверки на попадание значения атрибута в
заданный диапазон. Но могут быть и более сложные виды фильтрации. Например,
проверка на принадлежность точки некоторому региону. Все облако точек
делится на N областей-регионов. Каждый регион имеет свой идентификатор —
число от 0 до N-1. Номер региона, к которому принадлежит точка передается в
шейдер через вершинный атрибут.
Далее пользователь может выбрать какие регионы показывать. Например: 3,
5 и 10. Могут выбраны одновременно несколько регионов. Поэтому uniform-
переменные attr1xMin и attr1xMax здесь уже не применимы. Вместо этого в
шейдер передается массив булевских uniform-переменных, которые определяют
видимость каждого региона:
uniform bool attr1xRegion[100];
if (attr1xRegion[int(attr1.x)] == false)
{
discardPoint = true;
}
Примеры применения.
Предложенный подход использовался для визуализации и фильтрации
каталога гипоцентров землетрясений (рис. 3.6, 3.7).
74
Рис. 3.6. Региональный каталог сейсмических событий в районе Курило-Камчатской дуги, по
данным КФ ГС РАН [88]
Рис. 3.7. Мировой каталог сейсмических событий USGS за 1900-2011 гг, по данным USGS
[100], в редакции А. В. Ландера (МИТП РАН)
Каждый гипоцентр имеет атрибуты: широта, долгота, глубина, дата, время
(час, мин, сек), магнитуда, регион.
Глубина задается своим реальным значением (от 5км до -700км) с типом
float и используется для вычисления цвета гипоцентра. Цветовое кодирование
позволяет лучше определить глубину гипоцентра при обычном (не-
стереоскопическом) просмотре, а также является традиционным обозначением в
геофизике. Цвет берется из линейной палитры от синего на малых глубинах до
красного на больших глубинах.
75
Магнитуда также задается реальным значением от 0 (если не определена) до
9.5 с типом float. Значения магнитуды от минимального до максимального
отображаются на диапазон размеров точек от 1го до 6ти пикселей.
Также происходит фильтрация гипоцентров по регионам. Для каждого
гипоцентра хранится идентификатор региона, к которому относится гипоцентр.
При выборе алгоритма фильтрации учитывались следующие условия: (1) регионы
не пересекаются и (2) одновременно можно выбирать несколько регионов.
Тестировался набор из 10 регионов для Курило-Камчатской дуги.
3.2. Объемные данные
Объемные данные — это данные, заданные в виде трехмерной матрицы
значений. Традиционно эти данные получаются в медицине с помощью методов
магнитно-резонансной томографии или рентгеновской компьютерной
томографии. Однако природа этих данных может быть любая. Возможны
геопривязанные объемные данные — когда ячейки объема расположены через
равные интервалы по долготе, широте и глубине.
Такие данные могут возникать в результате бурения в узлах периодической
решетки и измерения каких-либо параметров почвы, например, температуры.
Также объемные данные получаются с помощью метода сейсмотомографии,
который сейчас активно развивается [101, 102]. По аналогии с медицинской
томографией сейсмотомография позволяет получить распределение некоторых
пространственных характеристик земной коры путем анализа данных с сети
сейсмостанций, регистрирующих сейсмические волны от землетрясений.
Землетрясения создают продольные и поперечные волны, которые
обозначают буквами P и S соответственно. Скорости распространения
сейсмических волн различны и зависят от модуля упругости и плотности среды.
Это позволяет идентифицировать некоторые характеристики земной коры на пути
следования сейсмических волн. Результатом обработки множества данных
является трехмерная матрица (воксельный массив), в ячейках которой записано
76
значение отношения скоростей P-волн и S-волн в данной точке. Каждая ячейка
матрицы (воксель) имеет координаты: долгота, широта, глубина.
3.2.1. Прямой объемный рендеринг
Существует 2 основных метода для рендеринга объемных данных:
генерация полигональной сетки по объемным данным (алгоритм marching cubes
[103]) и прямой объемный рендеринг [104].
Для визуализации объемных данных на виртуальном глобусе был
предложен алгоритм на основе прямого объемного рендеринга.
Рассмотрим сначала, как работает прямой объемный рендеринг на основе
обзорной работы [105].
Для хранения объемных данных на видеокарте используется 3D-текстура. В
ней содержится не цвет, а скалярное значение (плотность ). В случае
сейсмотомографии — это значение параметра Vp/Vs, приведенное к интервалу
[0; 255]. Отдельно задается передаточная функция (transfer function), которая
ставит в соответствие плотности цвет (RGB) и прозрачность (A) и хранится на
видеокарте в виде 1D-текстуры.
Считается, что каждая ячейка объема испускает свет и поглощает свет.
Чтобы определить цвет пикселя итогового изображения пускается луч из камеры
через центр пикселя, и интегрируются оптические свойства объема вдоль хода
луча. Интеграл берется численно следующим образом.
Через равные интервалы берется значение из 3D-текстуры с учетом
трилинейной фильтрации. На основе этого значения с помощью передаточной
функции вычисляется цвет (RGB) и прозрачность (A). Цвета последовательно
смешиваются от задних к передним или наоборот (рис. 3.8). Формула смешивания
от задних к передним:
(3.6)
77
Суммирование ведется от до 0. и — цвет и прозрачность в точке
объема i. — накопленный цвет.
Рис. 3.8. Бросание лучей
3D-текстура привязывается к полигональной модели прямоугольного
параллелепипеда, и интеграл считается для каждого пикселя параллелепипеда.
Параллелепипед погружается в трехмерную сцену, где могут находиться и другие
объекты.
Существуют также разновидности прямого объемного рендеринга:
проекция максимума интенсивности: цвета не смешиваются вдоль луча,
а берется цвет точки с максимальной плотностью;
освещение: в каждой точки вычисляется нормаль по градиенту, и цвет
считается с учетом освещения (косинус угла между нормалью и источником
света);
изоповерхность: берутся только точки, значение плотности которых
равно заданному.
Существуют модификации базового алгоритма для увеличения
быстродействия [106], для улучшения качества визуализации [107], устранения
визуальных артефактов [108], для мультиобъемного рендеринга [109].
78
3.2.2. Алгоритм визуализации объемных данных на глобусе
Была поставлена задача разработать алгоритм для визуализации объемных
данных на виртуальном глобусе.
Будем рассматривать частный случай, когда объем ограничен двумя
параллелями, двумя меридианами и двумя уровнями высоты.
Для небольших объемов (с площадью крышки несколько десятков
квадратных километров) можно считать Землю локально плоской и выводить
объем традиционным способом в виде прямоугольного параллелепипеда (рис.
3.9). Сначала рендерятся подземные объемные данные, а затем трехмерный
рельеф в режиме прозрачности с помощью алгоритма, описанного в параграфе
2.2.
Рис. 3.9. Визуализация результатов сейсмической томографии в районе Ключевской группы
вулканов на Камчатке за 2004 год, по данным И. Ю. Кулакова (ИНГГ СО РАН)
Для больших объемов уже необходимо учитывать форму Земли. В
географических координатах (долгота, широта, высота) данные имеют
прямоугольный вид: координаты ячеек объема расположены в узлах равномерной
сетки. Но эти объемные данные необходимо вписать в часть объема глобуса,
ограниченную параллелями, меридианами и высотами (рис. 3.10).
Предлагается модификация алгоритма прямого объемного рендеринга для
рендеринга объемных данных на глобусе.
79
Рис. 3.10. Форма объема
1. Сначала генерируется полигональная поверхность объёма с заданным
уровнем приближения к поверхности эллипсоида. Далее эта поверхность
рендерится в 2 прохода.
2. Во время первого прохода происходит рендеринг в текстуру задней
части поверхности. Текстура имеет формат RGB и содержит числа с плавающей
точкой. В текстуру записываются декартовы координаты фрагментов задней
части поверхности (рис. 3.11).
Рис. 3.11. Проход 1: рендеринг задней поверхности объема в текстуру
3. Во время второго прохода рендерится уже передняя часть поверхности
объёма. Вычисляются декартовы координаты фрагмента, которые являются
координатами точки входа луча в объем. Также во фрагментный шейдер
передается текстура, полученная во время первого прохода. Из нее берутся
декартовы координаты точки выхода луча из объема.
80
4. Зная координаты точки входа луча и точки выхода луча, можно с
заданным шагом пройтись вдоль луча и получить декартовы координаты
промежуточных точек (рис. 3.12).
Рис. 3.12. Проход 2: рендеринг объемных данных
5. Декартовы координаты каждой из промежуточных точек можно
преобразовать в географические координаты на основе формул из статьи [110],
которые обеспечивают точность в 1см для высот меньше 1000км:
, (3.7)
, (3.8)
, (3.9)
, (3.10)
, (3.11)
, (3.12)
, (3.13)
, (3.14)
, (3.15)
81
где (x; y; z) – декартовы координаты точки, и – экваториальный и полярный
радиусы Земли, – вспомогательные переменные, lat – широта, lon
– долгота, h – высота.
6. Пользуясь начальным условием, что наш объём ориентирован вдоль
параллелей и меридианов, из географических координат точки можно получить
текстурные координаты в 3D-текстуре. Тем самым задача сводится к
оригинальному прямому объемному рендерингу: происходит чтение плотности из
текстуры, вычисление цвета с помощью передаточной функции и смешивание
цветов от дальних точек к ближним по формуле (3.6).
Результат применения алгоритма представлен на рисунке 3.13 на примере
восточной части Евразии. Использовался объем размером матрицы 241х241х24.
Шаг по долготе и широте 0.25 , шаг по глубине 25 км. Для наглядности была
использована передаточная функция с двумя пиками красного и синего цвета для
показа двух изоповерхностей.
Рис. 3.13. Визуализация результатов сейсмической томографии в восточной части Евразии,
по данным д.г.-м.н. И.Ю. Кулакова (ИНГГ СО РАН)
3.2.3. Анимация изменений в объеме
В отличие от медицинской томографии получение данных с сейсмостанций
ведется непрерывно. В ходе сейсмических и вулканических процессов
характеристики и структура земной коры меняются. Эти изменения можно
наблюдать, сравнивая данные сейсмотомографии за разные промежутки времени.
82
Особенно явно видны изменения в области активной вулканической
деятельности.
Пусть дана последовательность временных фреймов для одного и того же
географического объема с одним и тем же размером матрицы. Фреймы можно
показывать последовательно, один за другим. Либо можно сделать интерполяцию
во времени для каждого вокселя, пользуясь тем, что количество вокселей
одинаково во всех фреймах.
В обоих случаях нужно учесть важный момент. Ячейки объема содержат
значения, отнормированные к диапазону [0; 255], а передаточная функция
отображает это отнормированное значение в цвет. Для одного объема нормировка
происходит с учетом минимального и максимального значения плотности для
этого объема. Но для последовательности фреймов нужно брать минимальное и
максимальное значения по всех фреймов, т.к. значения могут колебаться от
фрейма к фрейму. Это гарантирует, что на всех фреймах одному и тому же
значению плотности будет соответствовать один и тот же цвет.
Анимация последовательности фреймов тестировалась на объемных данных
под Ключевской группой вулканов (рис. 3.9). Размер матрицы каждого фрейма
121х81х46, шаг по долготе и широте — 1”, по глубине — 1 км. Объем расположен
не полностью под поверхностью эллипсоида, a поднимается над ним на высоту 5
км. Большая часть надземного объема заполнена пустыми значениями. Меньшая
часть содержится внутри вулкана. Всего в последовательности 40 фреймов за 10
лет.
3.3. Выводы по 3 главе
В главе рассмотрены алгоритмы визуализации облаков точек и объемных
данных на виртуальном глобусе, сделаны следующие выводы:
1. Облака точек на глобусе имеют разную природу: научные данные (в
частности подземные геофизические данные, каталоги землетрясений), данные
лазерного сканирования. Развиваются методы визуализации облаков точек.
83
2. Разработан алгоритм визуализации облаков точек, который учитывает
особенности глобуса: использование географических координат, использование
чисел одинарной точности, которые приводят к эффекту дрожания (jittering),
большую площадь территории, которую может занимать облако точек.
Облако точек разбивается на фрагменты в географической системе
координат. Фрагменты показываются в зависимости от расстояния до
наблюдателя. Вычисляется расстояние видимости для каждого фрагмента.
Фрагменты низких уровней детализации не скрываются, а к ним добавляются
новые фрагменты. Для контроля отображения вершин используется вершинный
шейдер: вычисляются цвет и размер точек в зависимости от вершинных
атрибутов, производится фильтрация.
4. Разработанный алгоритм позволяет показывать на глобусе облака с
большим количеством точек (100 млн. и больше). Данный подход позволяет
визуализировать 3D-модели целых городов, полученные методом лазерного
сканирования.
5. Объемные данные на глобусе описывают распределение
пространственных характеристик среды: земной коры или атмосферы. Объемные
данные заданы в узлах географической сетки: через равные интервалы по долготе,
широте и высоте. При переходе к декартовым координатам объем приобретает
сложную пространственную форму.
6. Разработан новый алгоритм для визуализации объемных данных на
глобусе, который основан на алгоритме прямого объемного рендеринга. Алгоритм
отрисовывает объем в 2 прохода: сначала заднюю, а потом переднюю стенки
объема. Это позволяет получить декартовы координаты точек входа и выхода
луча из объема, затем получить декартовы координаты промежуточных точек,
перевести их в географические координаты, затем в текстурные координаты.
Далее алгоритм сводится к прямому объемному рендерингу.
7. Разработанный алгоритм позволяет изучать строение земной коры на
основе данных сейсмотомографии.
84
ГЛАВА 4. Описание программного комплекса
Недостаточно просто поместить геопространственные данные на
виртуальный глобус. Необходимо также обеспечить возможность комфортной
работы с данными и восприятия данных. Сюда входят: возможность удобного
ориентирования в больших массивах данных, возможность быстро перемещаться
к нужным данным, нужному участку глобуса, возможность включать и
выключать слои данных, менять настройки визуализации.
При работе с виртуальным глобусом пользователь должен иметь
возможность анализировать данные, получать ответы не только на вопросы из
разряда «Что здесь находится?», но и «Почему здесь это находится?», необходимо
задействовать пространственное, ассоциативное мышление [41]. Для решения
этих задач и используется виртуальное окружение.
Виртуальное окружение — это технология человеко-машинного
взаимодействия, которая обеспечивает погружение пользователя в виртуальную
реальность и предоставляет естественный интуитивный интерфейс для
взаимодействия с трехмерной средой [111].
Виртуальная реальность — это искусственно созданная трехмерная среда,
которая передаётся человеку через органы чувств: зрение, слух, осязание. Для
создания виртуальной реальности применяются сложные технические средства,
системы виртуального окружения. Пользователь может воздействовать на
трехмерную среду, которая обновляется в реальном времени.
Часто термины «виртуальная реальность» и «виртуальное окружение»
взаимозаменяемы, и являются почти синонимами.
Помимо синтеза виртуальной среды важным является взаимодействие с
виртуальным глобусом и данными на нем. Под взаимодействием понимается
следующее: перемещение в пространстве виртуального глобуса: режим полета,
режим прогулки, подземное перемещение; а также воздействие на глобус и
объекты на глобусе разными способами, включая графический интерфейс
85
пользователя (например, переключение видимости слоев, отдельных объектов,
переключение режимов визуализации глобуса).
Разработки в области взаимодействия в виртуальном окружении ведутся
уже больше 20 лет. Например, работы [112, 113] описывают разные способы
реализации такого взаимодействия. За последние годы появилось новое
поколение аппаратных средств, которые позволили удешевить разработку систем
виртуальной реальности. Это привело к появлению новых работ, включающих
разработки по взаимодействию с глобусом. Например, в работе [114] описывается
управление глобусом с помощью жестов руками. А в работе [41] —
взаимодействие с помощью сенсорной панели с поддержкой множественных
касаний (multi-touch). В работе [115] описывается взаимодействие с
геопространственными данными в виртуальной реальности в рамках
археологической реконструкции.
В параграфе 4.1 будет рассмотрен программный комплекс, который
включает реализацию алгоритмов, описанных в главах 2 и 3, обеспечивает
стереоскопическую визуализацию и взаимодействие с глобусом и данными в
виртуальном окружении. В параграфе 4.2 рассмотрена стереоскопическая
визуализация виртуального глобуса. В параграфе 4.3 описываются подходы к
навигации (перемещению в 3D-пространстве), естественному взаимодействию,
взаимодействию через графический интерфейс пользователя, взаимодействию с
помощью мыши.
4.1. Программный комплекс
Программный комплекс для визуализации виртуального глобуса и 3D-
данных на глобусе в стереоскопическом режиме реализует варианты
визуализации виртуального глобуса, описанные во второй главе, алгоритмы
рендеринга 3D-данных, описанные в третьей главе, поддерживает различные
стерео-режимы, режимы навигации и взаимодействие с 3D-данными.
Аппаратное обеспечение. Программный комплекс может работать на
современном аппаратном обеспечении, использовать 3D-мониторы, джойстики с
86
6ю-степенями свободы, сенсор Kinect. Подробнее это будет рассмотрено в
параграфах 4.2 и 4.3. Пример аппаратного обеспечения показан на рис. 4.1.
Спецификация оборудования приведена в приложении Г. Указанные
комплектующие доступны на рынке и имеют небольшую цену.
Рис. 4.1. Пример аппаратной конфигурации
Зависимости. Программный комплекс использует в своей работе
различные сторонние библиотеки. Диаграмма зависимостей между
используемыми библиотеками показана на рисунке 4.2.
Рис. 4.2. Зависимости от сторонних библиотек
87
В основе комплекса лежит графический инструментарий OpenSceneGraph,
который является надстройкой над OpenGL [117]. В OpenSceneGraph реализована
структура данных «граф сцены», которая является основой всего программного
комплекса, позволяет логически и пространственно организовывать 3D-модели в
трехмерной сцене. Также OpenSceneGraph включает множество подключаемых
модулей для доступа к различным форматам файлов.
Генерация тайлов рельефа виртуального глобуса осуществляется с
помощью инструментария osgEarth [52]. Он также включает множество удобных
классов для работы с геоданными и визуализации геоданных.
Графический интерфейс пользователя реализован с помощью
инструментария Qt [118]. Вывод OpenGL графики осуществляется с помощью
виджета QGLWidget.
Дополнительно используются библиотеки: Awesomium [119] — для показа
веб-страничек прямо в графическом окне (например, по клику на иконке),
DirectInput [120] — для связи с джойстиком, Kinect SDK — для связи с Кинектом
[121].
Архитектура. Программный комплекс использует модульную архитектуру.
Имеется ядро, которое отвечает за базовую функциональность: создание каркаса
комплекса, инициализацию графического окна и графического интерфейса
пользователя, управление режимами визуализации глобуса, навигацию по
глобусу. На рисунке 4.3 показаны основные классы ядра программного комплекса
и связи между ними.
Каркас программного комплекса задают классы инструментариев
OpenSceneGraph, osgEarth и Qt. Эти классы были модифицированы, дополнены и
добавлены новые классы. Комплекс позволяет работать с несколькими
независимыми трехмерными сценами параллельно. Класс View (вид) управляет
визуализацией одной трехмерной сценой. Это позволяет переключаться между
видами во время работы программы. Например, один вид может содержать
88
глобус, а другой вид — только некий набор 3D-данных без глобуса, как на
рисунке 4.20, либо другой глобус с другими данными.
Вид включает одну (в моно-режиме) или две (в стерео-режиме)
виртуальных камер (класс Camera), а также экземпляр класса CameraManipulator
для навигации по сцене. С каждой камерой связан графический контекст (класс
GraphicsContext), в который и происходит отрисовка.
Класс StereoViewer произведен от класса CompositeViewer из фреймворка
OpenSceneGraph и играет роль фасада, который отвечает за визуализацию. Он
запускает внутри себя цикл отрисовки и содержит коллекцию видов (View),
позволяет их создавать и настраивать стерео-режимы. StereoViewer расширяет
функциональность базового класса единообразной поддержкой
стереовизуализации для разных стереорежимов. Для трекинга головы с помощью
сенсора Kinect он обращается к классу KinectAdapter.
Рис. 4.3. Основные классы ядра программного комплекса
Класс ViewManager занимается настройкой, высокоуровневым управлением
трехмерной сценой и содержит ряд инструментов для работы со сценой. Picker –
позволяет взаимодействовать с объектами сцены с помощью инструмента
«виртуальная лазерная указка», LaserPointer – рисует луч указки, SceneRoot –
89
настраивает графические эффекты, EarthManager – управляет режимами
визуализации глобуса (класс MapNode) и атмосферы (класс SkyNode).
Для навигации используются несколько классов, производных от
CameraManipulator. Они рассчитывают матрицу вида на основе входных данных
от органов управления: мыши, клавиатуры, джойстика. Разные классы реализуют
разные режимы навигации. Они могут использовать данные от устройств ввода
(класс Device), таких как джойстик SpaceNavigator (класс SpaceNavDevice).
Для управления трехмерной сценой через графический интерфейс
используется класс MainWindow, производный от QMainWindow.
Подключаемые модули. На базе ядра программного комплекса можно
разрабатывать производные приложения или дополнительные подключаемые
модули для решения конкретных практических задач. Каждый подключаемый
модуль содержится в своей динамически подключаемой библиотеке dll. Типовая
схема подключаемого модуля показана на рис. 4.4.
В ядре объявлен интерфейсный класс IPluginBase, от которого должны
наследоваться классы-загрузчики подключаемых модулей. При загрузке dll с
модулем в память создаются экземпляры этих классов и помещаются в
PluginRegistry, который реализован с помощью шаблона проектирования
«Синглтон».
Загрузчик — компонент, который вызывается из ядра программного
комплекса (через PluginRegistry) и настраивает модель и контроллер для
дальнейшей работы.
Модель — компонент, который отвечает за загрузку полезных данных,
создание 3D-объектов и подключение их к трехмерной сцене, и выполнение над
ними операций;
Контроллер — компонент, который создает графический интерфейс на
основе фреймворка Qt (класс Widget) и вставляет его в главное окно. При
взаимодействии пользователя с виджетами контроллер посылает команды
модели. Дополнительно может быть класс EventHandler для обработки событий
клавиатуры.
90
В рамках комплекса может быть подключено любое количество таких
модулей. Программный комплекс можно в дальнейшем неограниченно расширять
и применять для визуализации различных типов геопространственных данных.
Рис. 4.4. Основные классы подключаемого модуля
Далее более подробно будут рассмотрены 3 аспекта: поддержка
стереоскопической визуализации, режимы навигации и взаимодействие с
данными.
4.2. Стереоскопическая визуализация
Стереоскопическая визуализация — это вид визуализации, при котором
синтезируются 2 изображения с 2х виртуальных камер, одно изображение — для
левого глаза, другое — для правого. Это позволяет воспринимать форму, размер и
расстояние до объектов. Стереовизуализация — основное средство создания
виртуальной реальности.
Человек использует разные факторы для определения глубины до
предметов. Ряд из них доступен для одного глаза: размеры предмета, тени,
перекрытия предметов, априорные знания.
Три фактора доступны только при бинокулярном зрении, т.е. при
использовании 2-х глаз [122]:
91
бинокулярная диспарантность — основана на параллаксе (изображения
сдвинуты друг относительно друга из-за расстояния между глазами);
вергенция — вращение глазных яблок, чтобы сфокусироваться на
предмете;
аккомодация — изменение кривизны хрусталика, необходимое, чтобы
сфокусироваться на предмете.
В современных системах виртуального окружения стереоскопический
эффект достигается за счет использования первых двух факторов: бинокулярной
диспарантности и вергенции.
Первые системы виртуального окружения возникли более 30 лет назад. Они
были громоздкие и дорогостоящие и применялись для узких задач. Однако
последние годы, благодаря росту производительности персональных
компьютеров, эта тема снова начала активно развиваться. Здесь нужно упомянуть
Джеймса Кэмерона, который снял фильм Аватар в стерео в 2009 году и тем самым
популяризировал идею стереовизуализации [123]. Фирма NVIDIA выпустила
недорогие затворные очки 3d vision, а производители мониторов выпустили
совместимые мониторы с частотой 120Гц [116].
4.2.1 Технологии стереовизуализации
Для обеспечения стереоскопической визуализации необходимо
взаимодействие 3х компонентов: приложение, которая генерирует изображения
для 2х глаз; видеокарты, которая может поддерживать специальный режим для
стерео; системы отображения (включает в себя и очки).
В настоящее время существует множество систем отображений, которые
применяют различные технологии для разделения изображений для 2х глаз.
Кратко перечислим системы и соответствующие технологии:
Анаглиф: простейшая и наиболее примитивная технология, с плохим
качеством восприятия. К изображениям для разных глаз применяются
программные цветофильтры: к одному — синий, к другому — красный, после
чего 2 изображения объединяются в одно, которое и выводится с помощью
92
самого обычного монитора или проектора. Для просмотра стереоизображения
нужно иметь очки со встроенными в них цветофильтрами [124, 125].
2х-проекторная система с использованием поляризации: используется
горизонтальная стереопара, левая половина которой отображается одним
проектором, а правая — другим. Для разделения изображений используются
поляризационные фильтры с линейной или круговой поляризацией, фильтры
устанавливаются на очки и на проекторы [111].
Черезстрочная поляризация: используется монитор или телевизор,
пиксели четных строк которого имеют одну поляризацию, а пиксели нечетных
строк — другую. Поэтому изображение, подаваемое на монитор, должно быть
составлено из двух изображений: четные строки от одного изображения, а
нечетные — от другого. Необходимы очки с поляризационными фильтрами.
Затворное стерео: изображение выводится на монитор или проектор с
частотой 120Гц, при этом очки синхронно с монитором попеременно открывают и
закрывают глаза.
Инфитек: используется спектральное разделение каналов. В компьютере
любой цвет задается комбинацией 3х базовых цветов: красного, зеленого и
синего. Но при выводе каждому из этих цветов соответствует диапазон длин волн.
Для левого и правого глаз выводятся немного отличающиеся длины волн. Глаз
отличия не воспринимает, но разница длин волн позволяет создать фильтры,
которые устанавливаются на очки и на выходе из проектора [126].
Шлем виртуальной реальности, в котором каждому глазу соответствует
свой мини-экран.
Некоторые стереорежимы могут работать без специальной поддержки
видеокарты: анаглиф, поляризационные системы. Изображение, сгенерированное
стандартным способом, просто посылается на систему отображения. Другие
режимы — затворное стерео и инфитек — требуют специального режима работы
видеокарты: квадробуфер, который доступен только на дорогих
профессиональных видеокартах Nvidia Quadro и AMD FirePro [127, 128].
93
Иногда также применяются термины «пассивное стерео» и «активное
стерео». Под пассивным стерео понимается система, когда изображения из 2х глаз
выводятся одновременно. Обычно это системы, основанные на поляризации. Под
активным стерео понимается система, когда изображения для 2х выводятся по
очереди, с частотой 120Гц. Сюда же относятся затворное стерео и инфитек, хотя
инфитек использует пассивные очки.
4.2.2. Настройка стереоэффекта в программном комплексе
Поддержать стереоэффект на уровне приложения можно несколькими
способами. В работе [129] описаны несколько подходов:
используется одна виртуальная камера, которая рендерится в 2 прохода.
После выполнения проекционного преобразования в вершинном шейдере
усеченные координаты сдвигаются влево или вправо. Этот вариант также
используется в стереодрайвере NVidia. Минус подхода — некорректное отсечение
невидимых объектов (culling);
используется одна виртуальная камера, которая рендерится в 2 прохода.
В каждом проходе используются свои модифицированные матрицы вида и
проекции. Это позволяет организовать корректное отсечение;
используются две виртуальные камеры. Каждая камера использует свои
матрицы вида и проекции.
Если приложение изначально разрабатывалось без учета стереоскопичекой
визуализации, то для быстрого подключения стерео можно использовать 1-й или
2-й варианты. Но при разработке новых приложений рекомендуется использовать
3-й вариант с двумя виртуальными камерами, как более гибкий. Он позволяет
поддержать различные стерео-режимы единообразным способом.
С точки зрения приложения можно выделить три основных стерео-режима,
которые отличаются настройками виртуальных камер.
горизонтальная стереопара (side-by-side): выходное изображение
состоит из двух половин, составленных рядом. Левая половина содержит
изображение для левого глаза, а правая половина — для правого глаза;
94
черезстрочное стерео: четные строки выходного изображения — это
строки изображения для левого глаза, а нечетные строки — для правого глаза;
квадробуфер: основан на использовании специального режима
видеокарты, при котором в видеопамяти отдельно создается буфер для левого
глаза и отдельно для правого. Каждый из них в свою очередь имеет задний буфер
(туда идет рендеринг) и передний буфер (он выводится на экран). Отсюда и
название режима.
Для настройки режимов в приложении нужно следовать следующим
рекомендациям. Пусть width и height — ширина и высота экрана в пикселях.
Случай горизонтальной стереопары распадается на два: используется один
видеовыход или два видеовыхода. Если видеовыход один, то нужно
проинициализировать один графический контекст, а 2 виртуальные камеры
должны различаться только портом просмотра (viewport). Левая камера должна
занимать левую половину окна, а правая – правую половину, а значит настройки
портов просмотра будут такие: (0, 0, width/2, height) и (width/2, 0, width/2, height).
Если видеовыхода два, то на каждый создается свой графический контекст,
и для каждого своя виртуальная камера.
В случае квадробуфера обе виртуальные камеры должны занимать все окно,
т.к порты просмотра будут одинаковые: (0, 0, width, height). Отличия будут в
буферах отображения. Согласно спецификации OpenGL левая камера должна
использовать буфер GL_BACK_LEFT, а правая — GL_BACK_RIGHT.
В случае черезстрочного стерео необходимо использовать буфер трафарета.
Сначала в буфер рендерится маска. В четные строки записывается значение 1, а в
нечетные — 0. Это удобно сделать с помощью функции OpenGL glPolygonStipple,
либо вручную. Далее рендерится сама трехмерная сцена. Для левой камеры нужно
включить тест буфера трафарета, который должен срабатывать только если в
буфере трафарета значение 0. Для правой камеры — только если в буфере
трафарета значение 1. Результат применительно к виртуальному глобусу показан
на рисунке 4.5.
95
Рис. 4.5. Виртуальный глобус в режиме черезстрочного стерео
4.2.3. Учет разброса масштабов для виртуального глобуса в программном
комплексе
Математика стереоэффекта описана в приложении В, приведены формулы
расчета матриц вида и проекции для виртуальных камер. В случае, если масштаб
сцены слишком маленький или слишком большой по сравнению с реальными
размерами системы отображения, то необходимо применять параметр
«расстояние схождения» (fusion distance) для масштабирования виртуальной
системы отображения.
Но в случае виртуального глобуса возникает осложнение: большой разброс
масштабов. Мы хотим видеть глобус «объемным» из космоса и хотим ощущать
«объем» для объектов у поверхности глобуса и для космических аппаратов на
орбите. Для этого необходимо динамически изменять расстояние схождения в
зависимости от положения наблюдателя.
Существует два основных варианта вычисления расстояния схождения:
брать расстояние от камеры до точки на рельефе вдоль луча зрения;
брать высоту камеры над рельефом.
Было проведено сравнение обоих вариантов. Субъективно второй вариант
показал лучшее качество восприятия стереоэффекта особенно в гористом
рельефе.
Отдельная проблема возникает, если нужно приблизиться к объекту,
приподнятому над рельефом, например к космическому аппарату (спутнику),
96
летящему по орбите. В этом случае мы не сможем увидеть его вблизи: он будет
слишком маленьким по сравнению с расстоянием между камерами. Поэтому
нужно брать минимальное расстояние схождения:
, (4.1)
При приближении к поверхности формулу необходимо корректировать.
Пусть ed — высота камеры над рельефом (earth distance). Если , то на
вершинах небоскребов будет ощущаться сильное расхождение изображений. Для
отдельных зданий можно реализовать собственное вычисление fd и применять по
аналогии с формулой для спутников. Либо можно зафиксировать значение fd на
высотах ниже предельной высоты:
, (4.2)
В этом случае на высотах меньше , а значит , что
соответствует реальным параметрам виртуальных камер. можно взять,
например, 100 м.
4.3. Навигация и взаимодействие
4.3.1. Навигация
Навигация — это управление перемещением виртуальной камеры по
трехмерной сцене. Управление может осуществляться от клавиатуры, мышки,
джойстика или другими способами. Существует несколько моделей движения.
Они описаны в работах [112, 113]. В случае виртуального глобуса есть свои
особенности.
Обзор моделей движения
Конечным результатом навигации является матрица вида, которая содержит
положение и ориентацию виртуальной камеры. Матрица вида выполняет
преобразование из мировой в видовую систему координат. Центр видовой
97
системы координат связан с центром камеры. Камера смотрит вдоль
отрицательного направления оси Z. Ось X направлена вправо, ось Y — вверх [71].
Матрица вида переводит координаты вершины из мировой СК в
видовую СК. Обратную ей матрицу можно назвать матрицей
наблюдателя, т.к. она описывает положение наблюдателя (камеры) в мировой СК.
В дальнейшем будет удобно работать именно с . Каждый кадр необходимо
на основе данных с устройств ввода обновлять значение и затем получать
.
Все модели движения можно разбить на два класса: центр вращения (pivot)
совпадает с камерой или центр вращения вынесен вперед.
1. В модели, когда центр вращения совпадает с камерой, состояние
камеры определяется 2мя параметрами: вектор положения центра камеры в
мировой СК (и соответствующая ему матрица сдвига) и кватернион вращения (и
соответствующая ему матрица вращения). Оба параметра изменяются
независимо. Итоговая матрица вычисляется так:
(4.3)
Это можно представить следующим образом: сначала камера находится в
начале координат (в видовой СК), затем мы вращаем камеру и сдвигаем в нужную
точку.
2. В модели с вынесенным вперед центром вращения состояние камеры
определяется 3мя параметрами: вектор положения центра вращения (и
соответствующая ему матрица сдвига), кватернион вращения относительно
центра вращения (и соответствующая ему матрица вращения) и расстояние от
центра вращения до камеры (ему соответствует матрица сдвига по оси Z). В
случае глобуса центр вращения естественным образом должен находиться на
поверхности глобуса. Итоговая матрица вычисляется так:
(4.4)
98
Это можно представить следующим образом: сначала камера находится в
начале координат (в видовой СК), затем мы отодвигаем камеру на расстояние d
по оси Z, затем вращаем камеру вокруг начала координат, затем двигаем начало
координат (центр вращения) в заданную точку в мировой СК.
В случае глобуса удобнее использовать немного другой подход. В точке
вращения вводится локальная система координат (рис. 4.6) и формируется
матрица перевода в мировую систему координат . А кватернион вращения
задается в этой локальной системе координат. Тогда итоговая матрица будет
выглядеть так:
(4.5)
Это показано на рисунке 4.7.
Рис. 4.6. Локальная система координат на глобусе
Каждая из этих двух моделей имеет свои преимущества и недостатки.
Можно провести следующие ассоциации.
В случае модели, когда центр вращения совпадает с камерой, пользователь
ощущает себя персонажем в виртуальном мире. Он может перемещаться (двигать
вектор положения) и вращать головой по сторонам (менять кватернион
вращения).
В модели, когда центр вращения вынесен, пользователь ощущает себя
исследователем, который крутит в руках объект. При использовании этой модели
99
может сложиться впечатление, что не пользователь двигается вокруг объекта, а
пользователь неподвижен и двигает объект.
Рис. 4.7. Задание положения камеры
Преимуществом модели с вынесенным центром вращения является
возможность одним движением мыши облететь вокруг объекта на поверхности
глобуса. При этом сначала центр вращения сдвигается в точку расположения
объекта, и затем мышкой меняется только матрица вращения.
Но модель, когда центр вращения совпадает с камерой, является более
гибкой. Она позволяет реализовать дополнительно режим прогулки по рельефу,
когда камера зафиксирована над рельефом на заданной высоте, и режим
подземного перемещения.
При использовании джойстика с 6-ю степенями свободы также более
удобным является вариант, когда отдельно задается положение и отдельно
вращение. Три степени свободы джойстика соответствуют перемещению камеры
в мировой СК. Другие три степени вращения — соответствуют вращению
камеры. При использовании такого джойстика удобна ассоциация именно с
поворотами головы.
Комбинированный вариант между двумя моделями движения реализован в
Google Earth. Для задания положения камеры центр вращения не используется, но
100
при вращении он динамически вычисляется в месте клика мышкой по рельефу, а
не задан принудительно. Т.е. камера вращается вокруг точки, куда кликнула
мышка.
Реализация в программном комплексе
Сдвиг камеры в мировой СК в каждый момент времени можно разложить
по 3м взаимно перпендикулярным осям, которые образуют локальную СК (рис.
4.6). Центр локальной СК совпадает с текущим положением камеры. Два вектора
направлены «вправо» и «вверх» в тангенциальной плоскости. Третий вектор —
это вектор нормали к эллипсоиду в этой точке.
При движении в тангенциальной плоскости расстояние до центра глобуса
необходимо поддерживать постоянным. Также необходимо корректировать
вращение камеры, чтобы оно оставалось постоянным в локальной системе
координат.
Вращение камеры можно реализовать 2мя основными способами: «ведение»
и «взаимодействие». В режиме «ведения» камера поворачивается вслед за
мышкой. Если мышка движется влево, то и камера движется влево. При этом
кусор мыши делается невидимым. В режиме «взаимодействие» мышка не
оказывает влияние на камеру. Можно выбрать любой объект на экране и нажать
на него.
Управление от клавиатуры и мыши описано в таблице 1. Однако
рекомендуется использовать джойстик с 6-ю степенями свободы, которые
непосредственно отображаются на перемещение камеры.
Каждый кадр необходимо пускать из камеры луч вниз по нормали к
эллипсоиду для определения точки пересечения с рельефом и вычисления
расстояния до рельефа. Это расстояние — важная переменная, которая
используется для нескольких задач. Например, скорость движения удобно
привязать к высоте над рельефом. Эмпирически подобран коэффициент
пропорциональности 1,5.
, (4.6)
101
где – минимальная скорость, которую можно положить 1.0 м/c для
комфортного перемещения на малых высотах.
Зная высоту над рельефом, можно корректировать эту высоту, например, не
давать камере опуститься ниже высоты 1 м. Либо можно принудительно
зафиксировать высоту 1,8 м, тогда это будет режим прогулки.
В режиме спуска под землю нужно отключить проверку на минимальную
высоту, а выбрать равным 100 м/c.
Таблица 1
Отображение событий устройств ввода на движение камеры
Событие Действие
Левая кнопка мыши Выбор 3D-объектов в режиме «Взаимодействие»
Правая кнопка мыши Переключение режимов «Ведение» и «Взаимодействие»
Колесико Движение вдоль луча в направлении курсора мыши
Кнопки qwes Перемещение параллельно поверхности эллипсоида
Кнопки ad Вращение вокруг нормали к эллипсоиду
Кнопки rf Движение вдоль нормали к эллипсоиду
4.3.2. Естественное взаимодействие и трекинг головы
Стереоскопическая визуализация — не единственный инструмент
достижения «погружения» в виртуальную среду. В последние 2-3 года начало
активно развиваться, так называемое, «естественное взаимодействие» человека с
компьютером (natural interaction).
Обзор естественного взаимодействия
Естественное взаимодействие — это технология человеко-машинного
взаимодействия, основанная на использовании жестов, движений тела, головы,
голосовых команд. Это интуитивно простой способ взаимодействия с данными.
Первые работы в этом направлении были сделаны более 10 лет назад [130].
Одни из первых технических средств — это джойстики с 6ю степенями свободы
[131] и сенсорные экраны с поддержкой множественного касания (multitouch)
102
[41]. Такие экраны с помощью движений нескольких пальцев по экрану
позволяеют двигать, вращать и масштабировать двумерные изображения.
Дальнейшее развитие этой технологии связано с появлением в конце 2010
года устройства Microsoft Kinect, основанного на технологиях израильской
компании PrimeSense [121]. Kinect содержит несколько сенсоров: сенсор глубины,
цветную камеру и набор из 4-х микрофонов (рис. 4.8). Сенсор глубины состоит из
двух частей: эмиттера, который излучает сигнал в инфракрасном диапазоне; и
инфракрасной камеры, для определения отраженного инфракрасного света.
Рис. 4.8. Строение устройства Microsoft Kinect
На вход компьютеру поступает два видеопотока (цветной и с картой
глубин) и звук из микрофонов. Специальное программное обеспечение позволяет
выделить на карте глубин точки, принадлежащие разным частям тела человек, и
построить на основе этих данных скелет [132, 133]. Изменение положения костей
скелета во времени можно использовать для выделения жестов и реакции на них.
Сигнал с микрофонов очищается от фонового звука и может использоваться для
распознавания речи. Система позволяет одновременно определять скелеты 2х
человек в кадре и разделять общий звуковой сигнал по голосам отдельных людей.
Для работы с Kinect существует два инструментария для разработки:
официальный SDK от компании Microsoft, который работает только под Windows,
и неофициальный кроссплатформенный OpenNI, поддерживающий и другие
аналогичные сенсоры [134].
103
В настоящее время наиболее очевидное и популярное применение Kinect —
видеоигры. Перспективно использовать его в научных приложениях для более
удобного и интуитивного управления приложением для визуального анализа.
Появились работы, посвященные управлению виртуальным глобусом с помощью
жестов [114, 135].
Недавно было анонсировано устройство Leap Motion, которое
предназначено для высокоточного отслеживания пальцев рук, что позволит
двигать курсор мыши пальцами и нажимать на кнопки графического интерфейса
легким жестом указательного пальца в воздухе [136]. В версию Google Earth 7.1
была добавлена поддержка Leap Motion [137].
В целом задача распознавания жестов и голосового управления выходит за
рамки данной диссертации. Однако в теме естественного взаимодействия можно
выделить задачу использования трекинга головы в виртуальном окружении.
В схеме, описанной в приложении В, предполагалось, что голова
наблюдателя фиксирована относительно экрана. Однако в реальности это не так.
Даже если наблюдатель сидит четко перед экраном, его голова может отклоняться
в разные стороны.
Трекинг головы (и в том числе трекинг глаз) позволяет скорректировать
параметры виртуальных камер в соответствии с реальным положением глаз
наблюдателя относительно экрана. Это способствует более глубокому
«погружению» и реалистичному восприятию объема. Основной минус трекинга
головы — изображение на экране становится адаптированным только под одного
наблюдателя. Соседним зрителям будет некомфортно смотреть на экран. Поэтому
трекинг головы предназначается в первую очередь для индивидуального
использования.
Системы трекинга головы существуют и разрабатываются довольно давно.
Стоимость таких системы может достигать тысяч долларов и предназначены они
для использования вместе с дорогостоящими системами визуализации [138].
104
Поддержка Kinect в программном комплексе
В программном комплексе используется Microsoft Kinect для организации
простого трекинга в рамках автоматизированного рабочего места. Конечно,
точность трекинга оставляет желать лучшего [133]. Но плюсами устройства
являются его дешевизна и отсутствие необходимости в долгой настройке.
Устройство нужно разместить прямо под монитором и направить на пользователя
(рис. 4.9).
Рис. 4.9. Расположение монитора, Кинекта и пользователя
Программное обеспечение для связи с Кинектом позволяет получить
координаты 20 вершин скелета, одна из которых относится к голове (рис. 4.10).
Зная координаты головы, можно получить координаты двух глаз. Существуют
алгоритмы для определения поворотов головы. Существует библиотека Face
Tracking для построения полигональной сетки лица, что позволяет более точно
определить координаты глаз [139].
Зная координаты глаз, можно вычислить параметры виртуальных камер: их
матрицы вида и проекции. Изначально координаты находятся в системе
координат Кинекта. На рисунке 4.9 показан ось Z этой системы координат. Она
выходит из Кинекта вдоль оптической оси датчика глубины.
105
Рис. 4.10. Вершины скелета
Связь между всеми системами координат можно изобразить в виде графа на
рисунке 4.11. Удобно считать, что модуль навигации, описанный в параграфе 4.1,
воздействует на условную точку, которая закреплена относительно экрана и
находится перед ним на расстоянии sd. Будем называть эту точку стереоцентром
(рис. 4.12). Кинект зафиксирован относительно стереоцентра. Его положение в
системе координат стереоцентра задается матрицей . Положение глаз в
системе координат кинекта и . Итого матрицы вида для левого
и правого глаз вычисляются по формулам:
(4.7)
(4.8)
Матрицы проекции для виртуальных камер можно задать через параметры
left, right, bottom, top, znear, zfar:
, (4.9)
, (4.10)
, (4.11)
106
, (4.12)
где — сдвиг глаза относительно стереоцентра, sw — ширина экрана, а
sh — высота экрана.
Рис. 4.11. Связь систем координат
Эти параметры необходимо подставить в формулу вычисления матрицы
проекции [71]:
, (4.13)
4.3.3. Графический интерфейс пользователя
При работе с данными важной частью приложения является графический
интерфейс пользователя (Graphical User Interface, GUI). Графический интерфейс
— это совокупность, так называемых, виджетов, графических элементов
управления, расположенных на экране. Примеры виджетов: кнопки,
переключатели, ползунки, панели, меню.
107
Рис. 4.12. Виртуальная камера относительно центра
Существует множество программных библиотек, которые существуют и
применяются уже многие годы. Однако в случае стереоскопической визуализации
возникает ряд технических проблем. В данном параграфе эти проблемы будут
рассмотрены и будет приведен набор рекомендаций по реализации графического
интерфейса.
Все графические интерфейсы можно разделить на два типа: внешний и
встроенный.
Внешний графический интерфейс задает «каркас» окна приложения. Сюда
входит рамка окна, верхняя строка меню, панели с виджетами по бокам. А
графическое окно представляет собой лишь прямоугольный виджет, встроенный
внутрь окна приложения наравне с другими виджетами (рис. 4.13). Примеры
фреймворков для реализации внешнего интерфейса: Qt, WPF, MFC, wxWidgets.
Такой интерфейс применяется в основном для приложений, рассчитанных на
работу и взаимодействие с данными, анализ данных.
Внешний графический интерфейс хорошо сочетается со стереорежимами:
черезстрочное стерео и квадробуфер, т.к. эти режимы применимы к любой
прямоугольной области на экране. Однако режим горизонтальной стеропары не
совместим с внешним графическим интерфейсом. Приложение в этом режиме
принципиально является полноэкранным, и все виджеты должны дублироваться
108
на двух половинах экрана. Однако существующие фреймворки не рассчитаны на
такое применение.
Рис. 4.13. Внешний интерфейс на основе фреймворка Qt
Встроенный графический интерфейс находится внутри графического
окна и является 3D-объектом наравне с другими объектами трехмерной сцены
(рис. 4.14). Примеры фреймворков для реализации встроенного интерфейса:
Scaleform, CEGUI, MyGUI. Такой интерфейс применяется в основном в
компьютерных играх, симуляторах и тренажерах.
Встроенный интерфейс поддерживается стереорежимами: черезстрочное
стерео и квадробуфер. Режим горизонтальной стереопары технически возможен,
но не все популярные фреймворки для создания графического интерфейса его
поддерживают.
Но помимо этого имеется проблема восприятия встроенного интерфейса в
режиме стереовизуализации. Встроенный интерфейс является 3D-объектом в
виртуальной сцене и может пересекаться геометрически с другими объектами. В
монорежиме традиционно это решается путем принудительного рендеринга
интерфейса поверх основной сцены (с отключенным буфером глубины).
В случае стереорежима такой подход приводит к визуальному дискомфорту
и нарушению стереовосприятия. Действительно: трехмерный рельеф или другие
объекты «выдвигаются» из экрана, а меню закрывает часть рельефа и рисуется в
плоскости экрана. Получается, что глаз не понимает, на что ему фокусироваться:
109
на ближний объект (рельеф) или на более дальний объект (интерфейс), который
разрывает ближний объект.
Рис. 4.14. Встроенный интерфейс на основе фреймворка CEGUI
Компромиссный вариант — сначала рендерить интерфейс в плоскости
экрана, а затем поверх него трехмерный рельеф с включенной прозрачностью и
смешиванием цветов. Визуальный дискомфорт меньше, чем в предыдущем
случае, но все равно присутствует.
Радикальный вариант — разрешить пересечение рельефа с интерфейсом. В
этом случае возможна ситуация, когда рельеф полностью закрывает часть
интерфейса, и его функции становятся недоступными.
Благодаря стереовизуализации открывается еще одна возможность —
«выдвинуть» интерфейс из плоскости экрана вперед на такое расстояние, чтобы
оно не пересекалось с рельефом. Но при этом возникает сразу 2 новые проблемы.
Во-первых, если выдвинуть интерфейс слишком далеко из экрана, то глазам будет
трудно на нем сфокусироваться, и глаза станут быстро уставать. Во-вторых,
мышка движется в плоскости экрана, поэтому при фокусировке глаз на
интерфейсе, курсор мыши начнет раздваиваться и нажатие на виджеты будет
затруднено.
Итого есть четыре основных варианта взаимного рендеринга интерфейса и
других объектов в едином трехмерном пространстве:
интерфейс принудительно рендерится поверх других объектов;
110
цвет выступающих объектов смешивается с цветом интерфейса
(полупрозрачный режим);
объекты рендерится поверх меню без смешивания цветов;
меню выдвигается вперед из плоскости экрана.
Ни один из этих вариантов не является идеальным. Поэтому создавать
сложный встроенный интерфейс нужно осторожно случае стереовизуализации.
Полностью отказаться от него не всегда возможно. Поэтому учитывать несколько
рекомендаций: 1) интерфейс должен находиться в плоскости экрана; 2)
желательно, чтобы интерфейс был прижат к верхней границе экрана, в крайнем
случае — к левой или правой, т.к. трехмерный рельеф обычно выдвигается из
нижней части экрана.
4.3.4. Виртуальная лазерная указка
Помимо взаимодействия с графическим интерфейсом пользователю часто
необходимо взаимодействие с самими объектами трехмерной сцены. Типовой
пример: клик мышкой по объекту. После клика происходит какое-нибудь
действие с объектом. В моно-режиме определение, по какому объекту сцены был
произведен клик, происходит следующим образом. Из камеры через точку на
виртуальном экране, на которую указывает курсор мыши, пускается луч в
трехмерную сцены. Происходит проход по графу сцены и определение
пересечения луча с конкретным треугольником (рис. 4.15).
В случае стереовизуализации ситуация усложняется. Появляется 3
возможности пускания луча: из двух виртуальных камер или из средней точки
(рис. 4.16). Из соображений симметрии кажется, что пускать луч нужно из
средней точки. Однако при этом будет не очевидно, по какому объекту
производится клик. Видно, что за экраном лучи расходятся. Если объект на пути
среднего луча находится далеко от экрана, из виртуальных камер может
показаться, что мышка вообще не указывает на объект. Если фокусироваться на
объекте, то курсор мыши на экране раздваивается, а если фокусироваться на
курсоре — то объект.
111
Рис. 4.15. Луч из камеры через курсор мыши на экране
Рис. 4.16. Лучи из разных виртуальных камер через курсор мыши на экране
Поэтому в рамках программного комплекса предлагается инструмент
«Виртуальная лазерная указка». Необходимо отключить отображение курсора
мыши на экране. При этом пользователь продолжает двигать невидимый курсор
по экрану. Из средней точки через невидимый курсор на экране пускается луч на
трехмерную сцену и ищется пересечение с объектом (рис. 4.17). В найденной
точке отображается маркер — например, сфера или точка радиусом несколько
пикселей. Этот маркер — полноценный объект трехмерной сцены, и поэтому его
положение на экране для разных виртуальных камер будет разным. Параллакс для
112
маркера будет аналогичным параллаксу объекта, с которым было пересечение
луча. Поэтому такой подход не будет вызывать дискомфорта у глаз.
Рис. 4.17. Использование маркера внутри сцены вместо курсора мыши
Поиск пересечения луча с объектам должен происходить не по клику, а
каждый кадр. Тогда при движении курсора маркер будет плавно двигаться по
трехмерной сцене и создавать иллюзию движения курсора мыши. Если
пересечение с объектом не найдено, то маркер необходимо отобразить на
расстоянии от камеры, которое равно расстоянию до последней точки
пересечения. Такой маркер напоминает точку от луча лазерной указки (рис. 4.18).
Дополнительно реализован режим работы указки с включенным лучом
указки. Особенностью этого режима является то, что луч не должен исходить из
самой камеры, иначе он будет виден как точка на экране. Луч должен исходить из
точки, отстоящей немного вниз и вперед от камеры, как будто пользователь
держит указку в руке (рис. 4.19). Поиск пересечения с объектами теперь нужно
вести с помощью нового луча. Если вести поиск пересечения с помощью луча,
исходящего из камеры, то видимый луч указки будет пересекать другие объекты.
Предложенное решение позволяет интуитивно взаимодействовать с
объектами в виртуальном пространстве. Пример показан на рис. 4.20. При
двойном клике по объекту в левом верхнем углу высвечивается информация об
113
объекте. Аналогично на рис. 4.18 показан маркер без луча, который наведен на
иконку. При двойном клике по иконке выполнится привязанное действие.
Рис. 4.18. Маркер наведен на иконку
Рис. 4.19. Вид сбоку: луч лазерной указки исходит из точки вниз и вперед от камеры
Рис. 4.20. Пример использования лазерной указки в реальном проекте
114
4.4. Выводы по 4 главе
В главе описан программный комплекс для визуализации виртуального
глобуса и 3D-данных на глобусе и сделаны следующие выводы:
1. Программный комплекс реализует режимы визуализации глобуса (глава
2), разработанный способ визуализации полупрозрачной поверхности глобуса,
алгоритмы визуализации облаков точек и объемных данных (глава 3).
2. Для низкоуровневой работы с трехмерной графикой, построения глобуса
и графического интерфейса выбраны программные библиотеки OpenSceneGraph,
osgEarth, Qt и другие. Комплекс имеет модульную архитектуру, позволяет
использовать динамически подключаемые модули и работать одновременно с
несколькими трехмерными сценами, содержащими разные данные.
3. В случае глобуса существует особенность реализации стереоэффекта:
необходимо динамически менять расстояние между виртуальными камерами в
зависимости от расстояния до поверхности рельефа. Комплекс поддерживает
стереоскопическую визуализацию на современном оборудовании.
4. Существует несколько режимов навигации по сцене с виртуальным
глобусом, каждый из которых подходит для своих задач. В программном
комплексе реализованы разные режимы и переключение между ними.
5. В случае стереоскопической визуализации возникают проблемы
использования графического интерфейса пользователя и курсора мыши. Разные
виды графических интерфейсов имеют свои недостатки. В качестве
компромиссного решения выбран графический интерфейс на основе библиотеки
Qt. Для взаимодействия с 3D-объектами реализован инструмент «Виртуальная
лазерная указка», при котором вместо курсора мыши на поверхности 3D-объекта
показывается маркер, который движется в соответствии с невидимым курсором
мыши.
6. Программный комплекс может использоваться для автоматизации
рабочих местах в организациях, для анализа геопространственных данных в
различных областях науки и при проектировании.
115
ЗАКЛЮЧЕНИЕ
В рамках данной работы исследованы методы визуализации виртуального
глобуса, методы визуализации данных на глобусе, методы взаимодействия с
глобусом в виртуальном окружении, в том числе с помощью графического
интерфейса пользователя. Получены следующие результаты:
1. Разработан способ визуализации виртуального глобуса с полупрозрачной
поверхностью рельефа, который обеспечивает как надземный, так и подземный
просмотр геометрических объектов под поверхностью глобуса и устраняет
графические артефакты, вызванные перекрытием слоев рельефа и
вспомогательной геометрии.
Предложенный способ можно использовать для решения задач
реконструкции зданий и сооружений, в которых проектирование осуществляется
на основе облака точек. Способ позволяет анализировать расположение
проектируемого объекта относительно соседних зданий и окружающего рельефа,
учитывать трассировку подземных коммуникаций и т.д.
2. Разработан алгоритм визуализации облаков точек на глобусе с уровнями
детализации, учетом особенностей глобуса, контролем плотности точек на экране
и фильтрации по заданным критериям на графическом процессоре.
3. Разработан алгоритм визуализации объемных данных, заданных в
географической системе координат, который позволяет осуществлять просмотр
данных сейсмотомографии, в том числе производить анимацию изменений во
времени. Разработанные алгоритмы визуализации объемных данных и
полупрозрачной поверхности глобуса могут быть использованы для
представления и исследования процессов в земной коре с помощью данных
сейсмотомографии для больших территорий. Источником объемных данных
может быть также климатическое моделирование.
4. Разработан программный комплекс, который обеспечивает
визуализацию виртуального глобуса, данных и 3D-объектов на глобусе,
взаимодействие с ними в виртуальном окружении на современном оборудовании.
116
Разработанный программный комплекс может использоваться для организации
автоматизированного рабочего места. Он обеспечивает удобную навигацию в
трехмерном пространстве виртуального глобуса, стереоскопическую
визуализацию с учетом разных масштабов, поддержку графического интерфейса
пользователя.
Программный комплекс позволяет организовать стереовизуализацию в
домашних условиях, либо на рабочих местах в организациях. Он позволяет
работать с виртуальным глобусом и геопространственными данными в стерео и
может являться основой для дальнейшего развития 3D-ГИС.
Результаты данной работы были частично использованы в следующих
проектах: «Тренажер персонала Ленинградской АЭС», «Виртуальное Протвино»,
«Виртуальная Долина гейзеров», «Визуализация геофизических исследований»,
«Шуховская башня на Шаболовке», «Денисова пещера на Алтае».
Результаты работы демонстрируются посетителям Постоянно действующей
выставки достижений РАН и музея Кроноцкого государственного природного
биосферного заповедника.
117
БЛАГОДАРНОСТИ
Автор благодарен своему научному руководителю д.ф.-м.н. Афанасьеву
В.О. за поддержку при написании диссертации.
Автор благодарен д.ф.-м.н., проф. Клименко С.В. за поддержку при
написании диссертации и содействие в работе.
Автор благодарен к.ф.-м.н. Леонову А.В. за помощь и содействие в работе.
Автор благодарен Бакину Р.И. (ИБРАЭ РАН), Батурину Ю.М. (ИИЕТ РАН),
Вагину А.И. (МРТИ РАН), Шпиленку Т.И. (КГПБЗ) за финансовую поддержку
работы.
Автор благодарен Алешину В.П., Аникушкину М.Н., Белосохову Д.Е.,
Бугрову Н.В., Васину Ю.Г., Власенко А.В., Еремченко Е.Н., Жилиной Н.Д.,
Исламову Д.Р., Казанскому И.П., Клименко А.С., Конышеву В.А., Кулиеву В.М.,
Леженко А.И., Мещерину С.А., Петрову А.В., Петрухину В.А., Роткову С.И.,
Фролову П.В., Чеброву Д.В., Шурову А.И. за ценные замечания и дискуссии.
Автор благодарен Кугаенко Ю.А., Кулакову И.Ю., Ландеру А.В., Чеброву
В.Н. за предоставленные данные для тестирования.
Автор благодарен Российскому фонду фундаментальных исследований за
частичное финансирование исследования в рамках грантов 12-07-31043 мол_а, 10-
07-00407-а.
118
СЛОВАРЬ ТЕРМИНОВ
Буфер трафарета (англ. stencil buffer) – дополнительный буфер в памяти,
соответствующий по размеру выводимому кадру. Перед занесением цвета в буфер
цвета позволяет проводить специальный тест, наряду с тестом глубины.
Виджет (англ. widget) - графический элемент для управления программой.
Граф сцены (англ. scene graph) - древовидная структура данных для
логической и пространственной организации объектов трехмерной сцены.
Карта высот – изображение, в котором яркостью закодированы высоты
поверхности.
Карта нормалей – изображение, в котором цветом закодированы нормали к
поверхности.
Кэш (англ. cache) - хранилище промежуточных результатов работы для
ускорения доступа к ним.
Приложение (англ. application) - прикладная компьютерная программа.
Рендеринг (англ. rendering) - процесс отрисовки, синтеза графического
изображения
Тайл (англ. Tile) - прямоугольный элемент разбиения большого
изображения.
Текстура (англ. Texture) – изображение, накладываемое на 3D-модель.
Трекинг (англ. Tracking) – отслеживание положения определенного объекта
в пространстве с помощью специального оборудования.
Фреймворк (англ. framework) - промежуточное программное обеспечение,
которое формирует каркас приложения и влияет на его архитектуру.
Шейдер (англ. shader) - программа для одной из ступеней графического
конвейера, которая может включать матричные операции, вычисление освещения,
текстурирование и эффекты постобработки.
119
СПИСОК ЛИТЕРАТУРЫ
1. Леонов, А. В. 3D-документирование территории для систем виртуальной
реальности/ А. В. Леонов, А. Е. Бобков, Е. Н. Ерёмченко // Вестник
компьютерных и информационных технологий. - 2012. - Т. 9. - С. 13–17.
2. Алейников, А. А. Интерактивное 3D-приложение «Виртуальная Долина
гейзеров»/ А. А. Алейников, А. Е. Бобков, В. А. Дрознин // Компьютерные
инструменты в образовании. - 2011. - Т. 4. - С. 41–49.
3. Леонов, А. В. Виртуальное моделирование территории на основе данных
дистанционного зондирования/ А. В. Леонов, А. А. Алейников, А. Е. Бобков //
Известия высших учебных заведений. Геодезия и аэрофотосъёмка. - МИИГАиК,
2011. - Т. 2. - С. 46–52.
4. Алешин, В. П. Устройство для тренировки восприятия виртуального
пространства на основе адаптивной оптики/ В. П. Алешин, В. О. Афанасьев,
А. Е. Бобков // Приборы. - 2012. - Т. 11. - С. 35–41.
5. Бобков, А. Е. Разработка инструментария для показа стерео-презентаций
из файлов в KML-формате/ А. Е. Бобков, И. П. Казанский, С. В. Клименко //
MEDIAS 2010: Тр. междунар. науч. конф. - 2010. - С. 41–47.
6. Бобков, А. Е. Разработка инструментария для показа стерео-презентаций
из файлов в KML-формате/ А. Е. Бобков, И. П. Казанский, С. В. Клименко //
ГрафиКон’2010: Тр. 20-й Междунар. конф. по компьютерной графике и зрению. -
СПб., 2010. - С. 285–291.
7. Бобков, А. Е. Исследование и разработка методов визуализации
территорий на виртуальном глобусе/ А. Е. Бобков, С. В. Клименко, А. В. Леонов //
MEDIAS 2011: Тр. междунар. науч. конф. - 2011. - С. 33–37.
8. Бобков А. Визуализация сейсмических данных на виртуальном глобусе/
А. Бобков, А. Леонов, В. Чебров // ГрафиКон’2012: Сб. тр. 22 Междунар. конф. по
компьютерной графике и зрению. - М.: МГУ, 2012. - С. 163–168.
9. Aleshin, V. Visual 3D Perception of the Ski Course and Visibility Factors at
Virtual Space/ V. Aleshin, V. Afanasiev, A. Bobkov // 2011 International Conference
on Cyberworlds. - IEEE, 2011. - P. 222–226.
120
10. Бобков, А. Е. Интерактивная визуализация 3D данных на виртуальном
глобусе в стереоскопических системах (по материалам кандидатской
диссертации)/ А. Е Бобков // Тр. Междунар. конф. по физико-технической
информатике CPT2013. - Протвино-М.: Изд-во ИФТИ, 2013. - С. 75–84.
11. Белосохов, Д. Е. Возможности 3D-визуализации для эффективного
представления результатов научных исследований/ Д. Е. Белосохов, А. Е. Бобков,
А. В. Леонов // Проблемы комплексного геофизического мониторинга Дальнего
Востока России: Тр. третьей науч.-технической конф. - Петропавловск-
Камчатский, 2011. - С. 347–351.
12. Бакин, Р. И. 3D-реконструкция территории Ленинградской атомной
электростанции для задач моделирования чрезвычайных ситуаций/ Р. И. Бакин,
А. Е. Бобков, С. В. Клименко // Ситуационные центры и информационно-
аналитические системы класса 4i. SC-IAS4i-VRTerro2011: тр. Междунар. науч.
конф. – Протвино-М.: Изд. ИФТИ, 2011. – С.176-184.
13. Dodge M., McDerby M., Turner M. The Power of Geographical
Visualizations // Geographic Visualization Concepts Tools and Applications / Ed. by
M. Dodge, M. McDerby, M. Turner. John Wiley and Sons, 2008. P. 1–10.
14. Johnson, S. The Ghost Map: The Story of London’s Most Terrifying
Epidemic - and how it Changed Science, Cities, and the Modern World/ S. Johnson. -
Penguin, 2006.
15. Tomlinson, R. A geographic information system for regional planning/
R. Tomlinson // GA Stewart, (ed.: Symposium on Land Evaluation, Commonwealth
Scientific and Industrial Research Organization, MacMillan of Australia., Melbourne.
1968.
16. Foresman, T. The history of geographic information systems: perspectives
from the pioneers/ T. Foresman. - Prentice Hall PTR, 1998. ISBN: 0138621454.
17. Coppock, J. The history of GIS/ J. Coppock, D. Rhind // Geographical
information systems: Principles and applications. - 1991. - Vol. 1, № 1. - P. 21–43.
18. Koninger, A. 3D-GIS for urban purposes/ A. Koninger, S. Bartel //
GeoInformatica. - 1998. - Vol. 2, № 1. - P. 79–103.
121
19. Stoter, J. 3D GIS, where are we standing/ J.Stoter, S. Zlatanova //
Proceedings ISPRS Workshop on spatial, temporal and multi-dimensional data
modelling and analysis. - Quebec, Canada, 2003.
20. Дубинин, М. Отзыв на 3D ГИС Ульяновской области/ М. Дубинин. -
2011. URL: http://gis-lab.info/blog/2011-09/3dgis/.
21. Емельянова, Г. ГИС сегодня: тенденции, обзор/ Г. Емельянова. - 2012.
URL: http://isicad.ru/ru/articles.php?article_num=15737.
22. Емельянова, Г. Трехмерные ГИС приходят в Россию. Autodesk
Infrastructure Modeler как инструмент создания 3D ГИС/ Г. Емельянова,
И. Спивак, А. Шатохин. - 2012. URL: http://isicad.ru/ru/articles.php?
article_num=15195.
23. 3D World Atlas. URL: http://en.wikipedia.org/wiki/3D_World_Atlas.
24. Now a Virtual Globe, Not Just a World Atlas. 1997. URL:
http://www.microsoft.com/en-us/news/press/1997/nov97/vglobepr.aspx.
25. Bar-Zeev, A. The Word on Snow Crash and Google Earth/ A. Bar-Zeev. -
URL: http://www.realityprime.com/blog/2007/09/the-word-on-snow-crash-and-google-
earth/.
26. Gore, A. The Digital Earth : Understanding our planet in the 21st Century/
A. Gore. - 1998. URL: portal.opengeospatial.org/files/?artifact_id=6210.
27. Toutin T., Cheng P. QuickBird – a milestone for high-resolution mapping/
Toutin T., Cheng P. // Earth Observation Magazine. 2002. URL:
ftp://ftp.geogratis.gc.ca/part6/ess_pubs/ 219/219909/13212.pdf.
28. QuickBird specification. URL: http://www.digitalglobe.com/sites/default/
files/ QuickBird-DS-QB-PROD.pdf.
29. SRTM. URL: http://www2.jpl.nasa.gov/srtm/.
30. The History of the Modern Graphics Processor. URL: http://www.
techspot.com / article/650-history-of-the-gpu/.
31. Google Earth press release. URL: http://googlepress.blogspot.ru/
2009/02/introducing-google-earth-50_02.html.
122
32. Butler, D. Virtual globes: The web-wide world/ D. Butler // Nature. 2006.
URL: http://www.nature.com/nature/journal/v439/n7078/full/439776a.html.
33. Google Earth. URL: http://earth.google.com/intl/ru/.
34. NASA World Wind. URL: http://worldwind.arc.nasa.gov/index.html.
35. Turner, A. J. Introduction to Neogeography/ A. J. Turner // O’Reilly Media. -
2006.
36. Дмитриева, В. Т. Неогеография и стереотипы: новые подходы в
обучении/ В. Т. Дмитриева, Е. Н. Ерёмченко, С. В. Клименко, В. И. Кружалин //
Вестник Московского городского педагогического университета. Серия:
естественные науки. - 2009. - Т. 2. - С. 104–114.
37. Берлянт, А. М. Картография как форма существования навигации/
А.М. Берлянт // Земля из космоса: наиболее эффективные решения. - 2010. - Т. 6. -
С. 7–12.
38. Неогеография vs. картография. URL: http://www.neogeography.ru/rus/
news/articles/neogeography-vs-cartography-part-1.html.
39. i3D Virtual Globe. URL: http://www.fhnw.ch/habg/ivgi/forschung/i3d.
40. Schafhitzel, T. Real-time rendering of planets with atmospheres/
T. Schafhitzel, M. Falk, T. Ertl // Journal of WSCG. 2007. URL: http://www.vis.uni-
stuttgart.de/~falkmn/pubs/wscg07-schafhitzel.pdf.
41. Schoning, J. Improving interaction with virtual globes through spatial
thinking/ J. Schoning, B. Hecht, M. Raubal // Proceedings of the 13th international
conference on Intelligent user interfaces - IUI ’08. - New York, New York, USA: ACM
Press, 2008. - P. 129.
42. Christen, M. The Future of Virtual Globes The Interactive Ray-Traced
Digital Earth/ M. Christen // ISPRS Congress Beijing. - 2008.
43. Bernardin, T. et al. Crusta: A new virtual globe for real-time visualization
of sub-meter digital topography at planetary scales/ T. Bernardin, E. Cowgill,
O. Kreylos // Computers & Geosciences. 2011. Vol. 37, no. 1. P. 75–85.
44. Nebiker, S. Virtual Globes: Tech. rep./ S. Nebiker, S. Bleisch, E. Gulch. -
2010.
123
45. Christen, M. Large Scale Constraint Delaunay Triangulation for Virtual
Globe Rendering/ M.Christen, S. Nebiker // Advances in 3D Geo-Information Sciences/
Ed. by T. H. Kolbe, G. Konig, C. Nagel. - Berlin, Heidelberg: Springer Berlin
Heidelberg, 2011. - Lecture Notes in Geoinformation and Cartography. - P. 57–72.
46. Nebiker, S. Rich point clouds in virtual globes – A new paradigm in city
modeling?/ S. Nebiker, S. Bleisch, M. Christen// Computers, Environment and Urban
Systems. - 2010. - Vol. 34, no. 6. - P. 508–517.
47. Bleisch, S. Evaluating the appropriateness of visually combining
quantitative data representations with 3D desktop virtual environments using mixed
methods: Ph. D. thesis / S Bleisch. - 2011. - P. 208.
48. Cozzi, P. 3D Engine Design for Virtual Globes. A K Peters/ P. Cozzi,
K. Ring. - CRC Press, 2011. - P. 520. ISBN: 1568817118.
49. Outerra. URL: http://outerra.blogspot.ru/.
50. Руководство разработчика API Google Earth. URL:
https://developers.google.com/earth/documentation/index?hl=ru.
51. NASA World Wind Java SDK. URL: http://worldwind.arc.nasa.gov/java/.
52. osgEarth. URL: http://osgearth.org/.
53. Tile Feature Service. URL: http://wush.net/trac/osgearth/
wiki/HowToGenerateTFS.
54. Web Map Service specification. URL: http://portal.opengeospatial.org/
files/?artifact_id=14416.
55. Tile Map Service specification. URL: http://wiki.osgeo.org/wiki/
Tile_Map_Service_Specification.
56. Web Map Tile Service specification. URL: http://portal.opengeospatial.org/
f iles/?artifact_id=35326.
57. Web Coverage Service specification. URL: http://portal.opengeospatial.org/
files/?artifact_id=41437.
58. Web Feature Service specification. URL: http://portal.opengeospatial.org/
files/?artifact_id=39967.
124
59. KML Reference. URL: http://code.google.com/apis/kml/
documentation/kmlreference.html.
60. KML Specification. URL: http://www.opengeospatial.org/standards/kml/.
61. ESRI Shapefile Technical Description. URL: http://www.esri.com/
library/whitepapers/pdfs/shapefile.pdf.
62. Fan, M. A review of real-time terrain rendering techniques/ M. Fan, M. Tang,
J. Dong// 8th International Conference on Computer Supported Cooperative Work in
Design. - IEEE. - P. 685–691.
63. White M. Real-Time Optimally Adapting Meshes: Terrain Visualization in
Games // International Journal of Computer Games Technology. - 2008. – P. 1–7. URL:
http://www.hindawi.com/journals/ijcgt/2008/753584/.
64. Livny, Y. Seamless patches for GPU-based terrain rendering/ Y. Livny,
Z. Kogan, J. El-Sana // The Visual Computer. - 2009. - Vol. 25, no. 3. - P. 197–208.
65. Asirvatham, A. Terrain Rendering Using GPU-Based Geometry Clipmaps/
A. Asirvatham, H. Hoppe. - 2004. - P. 27–45. URL: http://research.microsoft.com/en-
us/um/people/hoppe/gpugcm.pdf.
66. Gorski, K. M. et al. HEALPix: A Framework for High Resolution
Discretization and Fast Analysis of Data Distributed on the Sphere/ K. M. Gorski,
E. Hivon, A. J. Banday // The Astrophysical Journal. 2005. Vol. 622, no 2. P. 759–771.
67. Dana, P. H. Geodetic Datum Overview / P. H. Dana. - URL:
http://www.colorado.edu/ geography/gcraft/notes/datum/datum.html.
68. Геоцентрическая и геодезическая системы координат. URL:
http://www.astronet.ru/db/msg/1190817/node25.html.
69. Kemen, B. Logarithmic Depth Buffer/ B. Kemen. - URL:
http://www.gamasutra.com/blogs/BranoKemen/20090812/2725/Logarithmic_Depth_Bu
ffer.php.
70. Ulrich, T. Rendering Massive Terrains using Chunked Level of Detail
Control/ T. Ulrich // Proceedings of the 2002 ACM SIGGRAPH conference. - 2002.
71. Shreiner D. OpenGL Programming Guide. 7 edition. Addison-Wesley,
2009. P. 1019.
125
72. Blinn, J. F. Models of light reflection for computer synthesized pictures/
J. F. Blinn // ACM SIGGRAPH Computer Graphics. - 1977. - Vol. 11, no. 2. - P. 192–
198.
73. NASA WMS. URL: http://neowms.sci.gsfc.nasa.gov.
74. Nishita, T. Display of the earth taking into account atmospheric scattering/
T. Nishita, T. Sirai, K. Tadamura, E. Nakamae // Proceedings of the 20th annual
conference on Computer graphics and interactive techniques -SIGGRAPH ’93. - 1993.
no. 2. - P. 175–182.
75. O’Neal, S. Accurate atmospheric scattering/ S. O’Neal // GPU Gems. -2005. -
Vol. 2. - P. 253–268. URL: http://http.developer.nvidia.com/GPUGems2/
gpugems2_chapter16.html.
76. Bruneton, E. Precomputed Atmospheric Scattering/ E. Bruneton, F. Neyret //
Computer Graphics Forum. - 2008. - Vol. 27, no. 4. - P. 1079–1086.
77. Harris, M. J. Real-Time Cloud Rendering/ M. J. Harris, A. Lastra // Computer
Graphics Forum. 2001. Vol. 20, no. 3. P. 76–85.
78. Wang, N. Realistic and Fast Cloud Rendering/ N. Wang // Proceedings of the
SIGGRAPH 2003 conference. - 2003. - P. 1–17.
79. Bruneton, E. Real-time Realistic Ocean Lighting using Seamless Transitions
from Geometry to BRDF/ E. Bruneton, F. Neyret, N. Holzschuch // Computer Graphics
Forum. - 2010. - Vol. 29, no. 2. - P. 487–496.
80. Wimmer, M. Light space perspective shadow maps/ M. Wimmer,
D. Scherzer, W. Purgathofer// Proceeding EGSR’04 Proceedings of the Fifteenth
Eurographics conference on Rendering Techniques. - Eurographics Association, 2004. -
P. 143–151.
81. Lagae, A. C. T. et al. State of the Art in Procedural Noise Functions/
A. Lagae, S. Lefebvre, D Rerose // EG 2010-State of the Art Reports. - 2010.
82. Everitt C. Interactive Order-Independent Transparency: Tech. rep.: 2001.
83. OpenGL depth buffer. URL: http://www.opengl.org/archives/
resources/faq/technical/depthbuffer.htm.
126
84. Baker, S. Learning to Love your Z-buffer/ S. Baker. - URL:
http://www.sjbaker.org/ steve/omniv/love_your_z_buffer.html.
85. Horizon culling. URL: http://blogs.agi.com/insight3d/index.php/
2008/04/18/horizon-culling/.
86. Lloyd, B. Horizon occlusion culling for real-time rendering of hierarchical
terrains/ B. Lloyd, P. Egbert. - 2002. - P. 403–410. - URL: http://dl.acm.org/
citation.cfm?id=602099.602162.
87. Геологическая служба США (USGS). URL: http://usgs.gov.
88. Камчатский филиал Геофизической РАН. URL: http://www.emsd.ru/.
89. Середович, В. А. Наземное лазерное сканирование/ В. А. Середович, А.
В. Комиссаров, Д. В. Комиссаров, Т. А. Широкова. - Новосибирск, 2009. - P. 261.
90. Rusu, R. B. 3D is here: Point Cloud Library (PCL)/ R. B. Rusu, S. Cousins //
Robotics and Automation (ICRA): 2011 IEEE International Conference. - 2011.- P.1–4.
91. Sainz, M. Point-based rendering techniques/ M. Sainz, R. Pajarola //
Computers & Graphics. - 2004. - Vol. 28, no. 6. - P. 869–879.
92. Linsen, L. Point cloud representation/ L. Linsen. - 2001. URL:
http://geom.ibds.kit.edu/papers/point_clouds.pdf.
93. Botsch, M. High-Quality Point-Based Rendering on Modern GPUs/ M.
Botsch, L.Kobbelt // PG ’03: Proceedings of the 11th Pacific Conference on Computer
Graphics and Applications, IEEE Computer Societ. - Washington, DC, USA, 2003- P.
335.
94. Rosenthal, P. Image-space point cloud rendering/ P. Rosenthal, L. Linsen //
Proceedings of Computer Graphics International. - 2008. - P. 136–143.
95. Schnabel, R. A Parallelly Decodeable Compression Scheme for Efficient
Point-Cloud Rendering/ R.Schnabel, S.Moser, R.Klein // Eurographics Symposium on
Point-Based Graphic. - 2007.
96. Schnabel, R. Octree-based Point-Cloud Compression/ R. Schnabel, R. Klein //
Eurographics Symposium on Point-Based Graphic. - 2006. - P. 111–120.
127
97. Mitra, N. J. Estimating surface normals in noisy point cloud data/ N. J. Mitra,
A. Nguyen, L. Guibas // International Journal of Computational Geometry &
Applications. - 2004. - Vol. 14. - P. 261–276.
98. Bruton, D. Approximate RGB values for Visible Wavelengths/ D. Bruton. -
URL: http://www.physics.sfasu.edu/astro/color/spectra.html.
99. OpenGL Shading Language specification. URL: http://www.opengl.org/
registry/ doc/GLSLangSpec.Full.1.20.8.pdf.
100. Каталог землетрясений USGS. URL: http://earthquake.usgs.gov/
earthquakes/feed/.
101. Кулаков, И. Ю. Геодинамические процессы в коре и верхней мантии
земли по результатам региональной и локальной сейсмотомографии: диссертация
на соискание ученой степени доктора геолого-минералогических наук/
И. Ю. Кулаков. - ИГМ СО РАН, 2007.
102. Koulakov, I. Feeding paths of the Kluchevskoy volcano group
(Kamchatka) from the results of local earthquake tomography/ I. Koulakov,
E. I. Gordeev, N. L. Dobretsov // Geophys. Res. Lett. - 2011. - Vol. 38.
103. Lorensen W. E., Cline H. E. Marching cubes: A high resolution 3D surface
construction algorithm / W. E. Lorensen, H. E. Cline // ACM SIGGRAPH Computer
Graphics. - 1987. - Vol. 21, no. 4. - P. 163–169.
104. Drebin, R. A. Volume rendering/ R. A. Drebin, L. Carpenter, P. Hanrahan
// ACM SIGGRAPH Computer Graphics. - 1988. - Vol. 22, no. 4. - P. 65–74.
105. Engel, K. Real-time volume graphics/ K. Engel, M. Hadwiger, J. M. Kniss
// Proceedings of the conference on SIGGRAPH 2004 course notes GRAPH ’04. - 2004.
- P. 29.
106. Гаврилов, Н. Стерео-визуализация научных и медицинских объемных
данных трассировкой лучей в реальном времени/ Н. Гаврилов, А. Белокаменская//
ГрафиКон’2010: Тр. 20-й Междунар. конф. по компьютерной графике и зрению. –
СПб., 2010. - С. 350–352.
107. Гаврилов Н., Турлапов В. Качественная объёмная визуализация
гигавоксельных массивов в блочном представлении на примерах данных из
128
медицины/ Н. Гаврилов, В. Турлапов // ГрафиКон’2012: Тр. 22-й Междунар. конф.
по компьютерной графике и зрению. – М.: МГУ, 2012. - С. 174–179.
108. Боголепов, Д. Высококачественная объемная визуализации в реальном
времени/ Д. Боголепов, И. Бугаев, Д. Сопин // ГрафиКон’2012: Тр. 22-й
Междунар. конф. по компьютерной графике и зрению. – М.: МГУ, 2012. - P. 169–
173.
109. Beyer, J. GPU-based Multi-Volume Rendering of Complex Data in
Neuroscience and Neurosurgery: Ph. D. thesis/ J. Beyer. - 2009.
110. Bowring, B. R. Transformation from spatial to geographical coordinates/
B. R. Bowring // Survey Review. - 1976. - Vol. 23, no. 181. - P. 5.
111. Клименко, С. В. AVANGO. Cистема разработки виртуальных
окружений/ С. В. Клименко, И. Н. Никитин, Л. Д. Никитина. – М.-Протвино, 2006.
112. Mine, M. Virtual environment interaction techniques/ M.Mine // UNC
Chapel Hill computer science technical report. - 1995. URL: http://lsc.univ-
evry.fr/~davesne/ens/pub/virtual_environment_interaction_techniqu_129302.pdf.
113. Robinett, W. Implementation of flying, scaling and grabbing in virtual
worlds/ W. Robinett, R. Holloway // Proceedings of the 1992 symposium on Interactive
3D graphics - SI3D ’92. - New York, New York, USA: ACM Press, 1992. - P. 189–192.
114. Stannus, S. Gestural navigation in Google Earth/ S. Stannus, D. Rolf,
A. Lucieer, W. Chinthammit // Proceedings of the 23rd Australian Computer-Human
Interaction Conference on - OzCHI ’11. - New York, USA: ACM Press, 2011. - P. 269–
272.
115. Bonfigli, M. E. The Aksum project: a VR GIS for a 3D inclusive interaction
with an archaeological landscape/ M. E. Bonfigli, M. Forte, A. Guidazzoli // Bar
international series. - 2003. - Vol. 1227. - P. 1–5.
116. NVIDIA 3d Vision. URL: http://www.nvidia.com/object/3d-vision-
glasses.html.
117. OpenSceneGraph. URL: http://openscenegraph.org.
118. Qt framework. URL: http://qt-project.org.
119. Awesomium. URL: http://awesomium.com.
129
120. DirectInput. URL: http://msdn.microsoft.com/en-us/library/windows/
desktop/ee416842(v=vs.85).aspx.
121. Microsoft Kinect. URL: http://www.microsoft.com/en-us/kinectforwindows.
122. Афанасьев, В. О. Системы 3D-визуализации индуцированной
виртуальной среды: Ph. D. Thesis/ В. О. Афанасьев. - 2007. - P. 211.
123. Elsaesser, T. James Cameron’s Avatar: access for all/ T. Elsaesser // New
Review of Film and Television Studies.- 2011. - Vol. 9, no. 3. - P. 247–264.
124. Beiser, L. Anaglyph Stereoscopy/ L.Beiser. - 1979.
125. Dubois, E. A projection method to generate anaglyph stereo images/
E. Dubois // 2001 IEEE International Conference on Acoustics, Speech, and Signal
Processing. Proceedings (Cat. No.01CH37221). - IEEE, 2001. - Vol. 3. - P. 1661–1664.
126. Jorke, H. Infitec-a new stereoscopic visualisation tool by wavelength
multiplex imaging/ H. Jorke, M. Fritz // Proceedings of Electronic Displays. - 2003.
URL: http://jumbovision.com.au/files/Infitec_White_Paper.pdf.
127. NVIDIA Quadro Quad Buffered Professional Stereo Technology. URL:
http://www.nvidia.com/object/quadro_stereo_technology.html.
128. OpenGL 4.3 specification. URL: http://www.opengl.org/registry/doc/
glspec43.core.20120806.pdf.
129. Gateau, S. Implementing Stereoscopic 3D in Your Applications/ S. Gateau,
S. Nash. - 2010. - URL: http://www.nvidia.com/content/GTC-2010/pdfs/
2010_GTC2010.pdf.
130. Zhai, S. Human performance in six degree of freedom input control: Ph. D.
thesis/ S. Zhai. - 1995. - P. 179.
131. 3d connexion. URL: http://www.3dconnexion.com/.
132. Shotton, J. Real-time human pose recognition in parts from single depth
images/ J. Shotton, T. Sharp, A. Kipman // Communications of the ACM. 2013. Vol.
56, no. 1. P. 116–124.
133. Azimi, M. Skeletal Joint Smoothing White Paper / M. Azimi. - URL:
http://msdn.microsoft.com/en-us/library/jj131429.aspx.
134. OpenNI. URL: http://www.openni.org/.
130
135. Boulos, M. N. K. Web GIS in practice X: a Microsoft Kinect natural user
interface for Google Earth navigation/ M. N. K. Boulos, B. J. Blanchard, C. Walker //
International journal of health geographics. - 2011. - Vol. 10. - P. 45.
136. Leap Motion. URL: https://www.leapmotion.com/.
137. Google Earth 7.1 released. URL: http://www.gearthblog.com/blog/archives/
2013/04/google-earth-7-1-released-adds-support-for-leap-motion.html.
138. Фурса, М. В. Исследование и разработка математического и
программного обеспечения оптичеких систем слежения реального времени для
приложений виртуального окружения: Ph. D. thesis. - 2009. - С. 132.
139. Face Tracking library. URL: http://msdn.microsoft.com/en-
us/library/jj130970.aspx.
140. Global Imagery Browse Services. URL: http://earthdata.nasa.gov/about-
eosdis/system-description/global-imagery-browse-services-gibs.
141. OpenWeatherMap. URL: http://openweathermap.org/.
142. DIVA GIS. URL: http://www.diva-gis.org/gData.
143. OpenStreetMap. URL: http://www.openstreetmap.org/.
144. Bourke, P. 3D Stereo Rendering Using OpenGL (and GLUT)/ P. Bourke. -
1999.URL: ftp://ftp.sgi.com/opengl/contrib/kschwarz/GLUT_INTRO/SOURCE/
PBOURKE/ index.html
131
ПРИЛОЖЕНИЕ А. Источники геоданных
Существуют различные данные ДДЗ в свободном доступе в интернете,
которые можно использовать для создания собственного глобуса.
Изображения Земли
Blue Marble Next Generation — самая известная коллекция изображений с
разрешением 500м/пк. Создана NASA путем обработки снимков со спутника
MODIS, сделанных в 2004 году. Имеются изображения для всех 12ти месяцев.
Изображения 3х типов: плоские, с данными топографии, с данными топографии и
батиметрии.
MODIS — спутниковые снимки с аппаратов MODIS, которые были
запущены на спутниках Терра (1999) и Аква (2002). Максимальное разрешение
250м/пк. Обновляются раз в день для всей Земли в нескольких спектральных
диапазонах.
Landsat — спутниковые снимки, сделанные спутником Landsat-7, который
был запущен в 1999 году. Максимальное разрешение 15м/пк. Сделаны в
нескольких спектральных диапазонах.
Высотные данные
GTOPO30 — глобальный набор высотных данных с разрешением 30
угловых секунд (~1км/пк). Создан в 1996 году Геологической службой США
(USGS). Данные собраны из различных источников растровой и векторной
топографической информации.
NASA Shuttle Radar Topography Mission (SRTM) — международный проект
по получению высотных данных высокого разрешения между 56 S и 60 N. В
феврале 2000 года была проведена радарная съемка земной поверхности с шаттла
Эндевор в ходе 11ти-дневной миссии. Разрешение исходных данных — 1 угловая
секунда (~30 метров/пк). Но данные такого разрешения были получены только
для территории США. Для остальной части мира разрешение — 3 угловые
секунды (~90 метров/пк). Вертикальная ошибка — примерно 16 метров.
132
Исходные данные проекта SRTM содержат дыры, т.е. области без высотных
данных. Эти дыры присутствуют в горных и пустынных районах. Для заполнения
дыр применяются различные алгоритмы интерполяции.
ASTER Global Digital Elevation Model (ASTER GDEM) — самая полная на
данный момент цифровая модель рельефа между 83 S и 83 N с разрешением
30м/пк. Выпущена в 2009 году. Получена на основе обработки стерео-пар
спутниковых снимков с аппарата ASTER. Вертикальная ошибка составляет 20
метров.
Батиметрия
ETOPO1 — цифровая модель рельефа всей Земли, включая рельеф морского
дна с разрешением 1 угловая минута (~1.8км/пк). Выпущена Национальным
управлением океанических и атмосферных исследований США (NOAA).
SRTM30_PLUS — цифровая модель рельефа всей Земли, включая рельеф
морского дна с разрешением 30 угловых секунд (~1км/пк).
Прочие данные
NASA регулярно публикует научные растровые данные для всей Земли [73,
140]. Сюда входят: температура суши и моря, толщина аэрозольного слоя,
концентрация углекислого газа, плотность растительного покрова, альбедо
поверхности.
Другие организации также выкладывают геопривязанные данные.
Геологическая служба США (USGS) в реальном времени публикует
землетрясения, происходящие в мире [100]. Также доступны архивные данные по
землетрясениям. Проект OpenWeatherMap публикует текущие погодные данные в
векторном и растровом форматах [141]. На сайте проекта DIVA-GIS
опубликованы свободные векторные данные низкого разрешения для всех стран
мира [142].
OpenStreetMap — картографический сервис, построенный про принципу
вики [143]. Этот сервис позволят создавать и редактировать векторную карту
Земли. Любой пользователь может нарисовать дороги, задать им свойства,
отметить здания, парки, леса, реки, объекты инфраструктуры. Теоретически,
133
возможны акты вандализма, когда вносятся заведомо недостоверные данные. Но
за счет очень большого количества участников, которые отслеживают
корректность данных, можно почти не сомневаться в точности. Данные сервиса
свободно доступны в растровом и векторном форматах.
134
ПРИЛОЖЕНИЕ Б. Шейдеры для объемной визуализации
1-й проход
Вершинный шейдер:
varying vec3 position;
void main(void)
{
position = gl_Vertex.xyz;
gl_Position = ftransform();
}
Фрагментный шейдер:
varying vec3 position;
void main(void)
{
gl_FragColor = vec4(position, 1.0);
}
2-й проход
Вершинный шейдер:
varying vec3 position;
varying vec3 lightDirection;
varying vec4 baseColor;
varying vec4 texBackCoord; //coord in offscreen texture
void main(void)
{
position = gl_Vertex.xyz;
gl_Position = ftransform();
texBackCoord = gl_ModelViewProjectionMatrix * gl_Vertex;
texBackCoord /= texBackCoord.w;
texBackCoord += vec4(1.0, 1.0, 1.0, 0.0);
texBackCoord *= vec4(0.5, 0.5, 0.5, 1.0);
baseColor = vec4(1.0, 1.0, 1.0, 1.0);
vec4 lightPosition = gl_ModelViewMatrixInverse * gl_LightSource[0].position;
if (lightPosition[3]==0.0)
{
// directional light source
lightDirection = -normalize(lightPosition.xyz);
}
else
{
// positional light source
lightDirection = normalize((lightPosition-gl_Vertex).xyz);
}
}
135
Фрагментный шейдер:
uniform sampler3D baseTexture;
uniform sampler1D tfTexture;
uniform float tfScale;
uniform float tfOffset;
uniform sampler2D backTexture;
uniform float SampleDensityValue;
uniform float TransparencyValue;
uniform float AlphaFuncValue;
varying vec3 position;
varying vec4 baseColor;
varying vec4 texBackCoord; //coord in offscreen texture
const float _radiusEquator = 6378137.0;
const float _radiusPolar = 6356752.3142;
const float flattening = (_radiusEquator-_radiusPolar)/_radiusEquator;
const float _eccentricitySquared = 2.0*flattening - flattening*flattening;
const float lon1 = 2.094395102393;
const float lon2 = 3.141592653589;
const float lat1 = 0.174532925199;
const float lat2 = 1.221730476396;
const float z1 = -25000.0;
const float z2 = -600000.0;
vec3 getTexCoord(vec3 pos)
{
float p = sqrt(pos.x*pos.x + pos.y*pos.y);
float theta = atan(pos.z*_radiusEquator, (p*_radiusPolar));
float eDashSquared = (_radiusEquator*_radiusEquator -
_radiusPolar*_radiusPolar) / (_radiusPolar*_radiusPolar);
float sin_theta = sin(theta);
float cos_theta = cos(theta);
float latitude = atan((pos.z +
eDashSquared*_radiusPolar*sin_theta*sin_theta*sin_theta) / (p -
_eccentricitySquared*_radiusEquator*cos_theta*cos_theta*cos_theta));
float longitude = atan(pos.y,pos.x);
float sin_latitude = sin(latitude);
float N = _radiusEquator / sqrt( 1.0 -
_eccentricitySquared*sin_latitude*sin_latitude);
float height = p/cos(latitude) - N;
float s = (longitude - lon1) / (lon2 - lon1);
float t = (latitude - lat1) / (lat2 - lat1);
float z = (height - z2) / (z1 - z2);
return vec3(s, t, z);
}
void main(void)
{
vec3 pos0 = texture2D(backTexture, texBackCoord.st).xyz;
136
vec3 pos1 = position;
const float max_iteratrions = 2048.0;
float num_iterations = ceil(1.0/SampleDensityValue);
if (num_iterations<2.0) num_iterations = 2.0;
if (num_iterations>max_iteratrions)
{
num_iterations = max_iteratrions;
}
vec3 deltaPosCoord=(pos1-pos0).xyz/float(num_iterations-1.0);
vec3 curpos = pos0;
vec4 fragColor = vec4(0.0, 0.0, 0.0, 0.0);
while(num_iterations>0.0)
{
vec3 texcoord = getTexCoord(curpos);
float v = texture3D(baseTexture, texcoord).a * tfScale + tfOffset;
vec4 color = texture1D(tfTexture, v);
float r = color[3]*TransparencyValue;
if (r>AlphaFuncValue)
{
fragColor.xyz = fragColor.xyz*(1.0-r)+color.xyz*r;
fragColor.w += r;
}
if (fragColor.w<color.w)
{
fragColor = color;
}
curpos += deltaPosCoord;
--num_iterations;
}
fragColor.w *= TransparencyValue;
if (fragColor.w>1.0) fragColor.w = 1.0;
fragColor *= baseColor;
if (fragColor.w<AlphaFuncValue) discard;
if (length(pos0.xyz) < 0.01)
{
discard;
}
if (length(fragColor.rgb) < 0.01)
{
discard;
}
gl_FragColor = fragColor;
}
При разработке шейдеров использовались формулы и фрагменты кода из
работ [117, 110].
137
ПРИЛОЖЕНИЕ В. Расчет стереоэффекта
Математика стереоэффекта подробно разобрана в работах [129, 144].
Пусть голова наблюдателя неподвижна и находится на расстоянии (screen
distance) от экрана и смотрит точно в центр экрана. Глаза сдвинуты влево и
вправо от положения головы на расстояние, где — расстояние между глазами
(interocular distance). Вид сверху изображен на рис. В.1. На рисунке показаны оси
координат видовой СК: ось X направлена вправо, а камера смотрит вдоль
отрицательного направления оси Z.
Рис. В.1. Вид сверху на главную камеру и положение глаз
Состояние виртуальной камеры описывается 2мя основными матрицами:
матрицей вида и матрицей проекции. В матрице вида заключено положение и
ориентация камеры. В матрице проекции — параметры объема видимости. Объем
видимости задается границами ближней плоскости отсечения (left, right, top,
bottom) и расстояниями до ближней и дальней плоскостей отсечения (near, far)
(рис. В.2).
Задача состоит в том, чтобы корректно посчитать матрицы вида и проекции
для 2-х камер, соответствующих глазам. В рамках вышеописанных ограничений
(голова зафиксирована относительно экрана) удобно хранить и вычислять
изменение матриц для условной центральной камеры, которая соответствует
138
голове. Например, алгоритмы навигации (параграф 4.3) должны возвращать
именно параметры для головы наблюдателя. Это позволяет уменьшить связность
между модулями навигации и стереоэффекта. Модуль навигации не должен
ничего знать про стереоэффект и иметь возможность работать без стерео.
Матрицы для виртуальных камер нужно вычислять путем домножения на
корректирующие матрицы.
Рис. В.2. Параметры матрицы проекции
Простейший (и неправильный) подход к виртуальным камерам состоит в
простом их сдвиге по оси X (рис. В.3). Этот подход не учитывает наличие экрана.
Реальному экрану (монитору) перед пользователем соответствует виртуальный
экран в трехмерной сцене. Здесь можно применить метафору окна. Экран — это
окно, через которое пользователь смотрит на трехмерную сцену.
Поэтому корректным будет конфигурация камер с учетом экрана на рис.
В.4. Можно заметить, что объем видимости становится не симметричным. Также
если 3D-объект находится на бесконечности (очень далеко), то расстояние между
его изображениями на экране должно равняться расстоянию между глазами
(примерно 0.06м).
139
Рис. В.3. Неправильный подход к стереоэффекту
Рис. В.4. Корректная конфигурация виртуальных камер
Для корректных расчетов необходимо задать следующие параметры:
ширину экрана, высоту экрана, расстояние до экрана и расстояние между глазами.
Делать это необходимо в тех единицах, которые используются в приложении.
Обычно это метры.
Для корректировки матрицы вида необходимо её домножить на матрицу
сдвига по оси X на для одной камеры и на для другой.
140
(В.1)
Исходная матрица проекции для условной центральной камеры —
симметричная. Нужно её также домножить на корректирующую матрицу, которая
изменяет форму области видимости. Изменение формы области можно достичь,
если применить ко всем вершинам всех объектов смещение по оси X,
пропорциональное расстоянию до камеры (рис. В.5).
Рис. В.5. Корректировка объема видимости
Матрица выглядит следующим образом:
(В.2)
Для правой камеры сдвиг будет в другую сторону.
Если всё это записать в матричной форме, то получится следующее:
(В.3)
Данные формулы используют реальные параметры в метрах: расстояние
между глаз и расстояние до экрана. Поэтому ощущения «объемности» и
расстояния до объектов будут примерно соответствовать ощущениям в реальной
141
жизни. Но, как мы знаем, для дальних объектов на расстоянии больше 50м
«объемность» почти не ощущается [122]. Земной шар из космоса представляется
Земным диском. Аналогичная ситуация имеет место в виртуальном окружении.
Действительно, параллакс для дальних объектов почти неотличим от расстояния
между глазами (примерно 0.06м).
Но всё преимущество систем виртуального окружения состоит именно в
ощущении объема. Для этого объект должен находиться в плоскости экрана и
иметь размеры, сопоставимые с плоскостью экрана. Желательно, чтобы объект
целиком умещался на экране. Тогда эффект будет максимальным: часть объекта
будет казаться за экраном, часть — перед экраном, и благодаря этому глаза будут
уставать меньше.
Но что, если объект слишком маленький (например, молекула) и находится
очень близко к камере (меньше половины расстояния до экрана) или слишком
большой (например, виртуальный глобус) и находится очень далеко (более чем в
100 раз дальше, чем экран)? В первом случае расстояние между изображениями
для левого и правого глаза будет очень сильно расходиться, и глаза не смогут
сфокусироваться. Во втором случае изображения будут на экране на расстоянии
iod, модель будет казаться на бесконечности и никакого положительного эффекта
«объемности» мы не почувствуем.
В этом случае можно пойти на сознательное искажение восприятия
реального объема объекта, чтобы улучшить восприятие объекта в целом. Для
очень больших объектов нужно всю сцену уменьшить в размерах, для маленьких
— соответственно увеличить в размерах. Однако использование матрицы
масштабирования нежелательно из-за возможных побочных эффектов. Вместо
этого можно изменить параметры виртуальных камер. Если на рисунке В.4
раздвинуть камеры, то автоматически увеличится расстояние до экрана
(плоскость пересечения объемов видимости будет считаться экраном). Как будто
виртуальный наблюдатель вырос в размерах. Это равносильно уменьшению
объекта. Удобно ввести параметр fd (fusion distance) — характерное расстояние до
объекта. Это расстояние, на котором должен находиться виртуальный экран. Для
142
объектов в плоскости экрана параллакс равен нулю. Отсюда и термин fusion —
схождение, слияние.
Тогда параметр s для сдвига камер в матрице (В.2) будет считаться по
формуле:
(В.4)
При этом матрица проекции останется без изменений.
143
ПРИЛОЖЕНИЕ Г. Аппаратное обеспечение
Спецификация аппаратного обеспечения, используемого для работы
программного комплекса.
• Процессор CPU Intel Core i5-3450 (3.1 ГГц/4core/SVGA HD Graphics
2500/1+6Мб/77 Вт/5 ГТ/с LGA1155)
• Материнская плата ASUS P8Z77-V PRO/THUNDERBOLT (RTL)
LGA1155 <Z77> 3xPCI-E+Dsub +DV+HDMI+miniDP/TB+GbLAN+WiFi
SATA RAID ATX 4DDR-III
• Оперативная память Corsair Vengeance <CMZ8GX3M1A1600C10> DDR-
III DIMM 8Gb <PC3-12800>
• Видеокарта 1Gb <PCI-E> DDR-3 PNY VCQ600(ATX)(V2)-T (OEM)
DVI+DP <NVIDIA Quadro 600>
• Жесткий диск SSD 128 Gb SATA 6Gb/s OCZ Vertex 4 <VTX4-25SAT3-
128G> 2.5"MLC+3.5"адаптер
• Жесткий диск HDD 1 Tb SATA 6Gb/s Western Digital Caviar Black
<WD1002FAEX> 7200rpm 64Mb
• Стерео монитор LG d2343p основе черезстрочного стерео
• Microsoft Kinect for Windows
• Джойстик 3dconnexion SpaceNavigator
144
145
146
147
148
149
