«Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования «Нижегородский государственный архитектурно-строительный университет» ...»
3.2.3. Анимация изменений в объеме
В отличие от медицинской томографии получение данных с сейсмостанций ведется непрерывно. В ходе сейсмических и вулканических процессов характеристики и структура земной коры меняются. Эти изменения можно наблюдать, сравнивая данные сейсмотомографии за разные промежутки времени. Особенно явно видны изменения в области активной вулканической деятельности.
Пусть дана последовательность временных фреймов для одного и того же географического объема с одним и тем же размером матрицы. Фреймы можно показывать последовательно, один за другим. Либо можно сделать интерполяцию во времени для каждого вокселя, пользуясь тем, что количество вокселей одинаково во всех фреймах.
В обоих случаях нужно учесть важный момент. Ячейки объема содержат значения, отнормированные к диапазону [0; 255], а передаточная функция отображает это отнормированное значение в цвет. Для одного объема нормировка происходит с учетом минимального и максимального значения плотности для этого объема. Но для последовательности фреймов нужно брать минимальное и максимальное значения по всех фреймов, т.к. значения могут колебаться от фрейма к фрейму. Это гарантирует, что на всех фреймах одному и тому же значению плотности будет соответствовать один и тот же цвет.
Анимация последовательности фреймов тестировалась на объемных данных под Ключевской группой вулканов (рис. 3.9). Размер матрицы каждого фрейма 121х81х46, шаг по долготе и широте — 1”, по глубине — 1 км. Объем расположен не полностью под поверхностью эллипсоида, a поднимается над ним на высоту 5 км. Большая часть надземного объема заполнена пустыми значениями. Меньшая часть содержится внутри вулкана. Всего в последовательности 40 фреймов за 10 лет.
3.3. Выводы по 3 главе
В главе рассмотрены алгоритмы визуализации облаков точек и объемных данных на виртуальном глобусе, сделаны следующие выводы:
1. Облака точек на глобусе имеют разную природу: научные данные (в частности подземные геофизические данные, каталоги землетрясений), данные лазерного сканирования. Развиваются методы визуализации облаков точек.
2. Разработан алгоритм визуализации облаков точек, который учитывает особенности глобуса: использование географических координат, использование чисел одинарной точности, которые приводят к эффекту дрожания (jittering), большую площадь территории, которую может занимать облако точек.
Облако точек разбивается на фрагменты в географической системе координат. Фрагменты показываются в зависимости от расстояния до наблюдателя. Вычисляется расстояние видимости для каждого фрагмента. Фрагменты низких уровней детализации не скрываются, а к ним добавляются новые фрагменты. Для контроля отображения вершин используется вершинный шейдер: вычисляются цвет и размер точек в зависимости от вершинных атрибутов, производится фильтрация.
- Разработанный алгоритм позволяет показывать на глобусе облака с большим количеством точек (100 млн. и больше). Данный подход позволяет визуализировать 3D-модели целых городов, полученные методом лазерного сканирования.
- Объемные данные на глобусе описывают распределение пространственных характеристик среды: земной коры или атмосферы. Объемные данные заданы в узлах географической сетки: через равные интервалы по долготе, широте и высоте. При переходе к декартовым координатам объем приобретает сложную пространственную форму.
6. Разработан новый алгоритм для визуализации объемных данных на глобусе, который основан на алгоритме прямого объемного рендеринга. Алгоритм отрисовывает объем в 2 прохода: сначала заднюю, а потом переднюю стенки объема. Это позволяет получить декартовы координаты точек входа и выхода луча из объема, затем получить декартовы координаты промежуточных точек, перевести их в географические координаты, затем в текстурные координаты. Далее алгоритм сводится к прямому объемному рендерингу.
7. Разработанный алгоритм позволяет изучать строение земной коры на основе данных сейсмотомографии.
- Описание программного комплекса
Недостаточно просто поместить геопространственные данные на виртуальный глобус. Необходимо также обеспечить возможность комфортной работы с данными и восприятия данных. Сюда входят: возможность удобного ориентирования в больших массивах данных, возможность быстро перемещаться к нужным данным, нужному участку глобуса, возможность включать и выключать слои данных, менять настройки визуализации.
При работе с виртуальным глобусом пользователь должен иметь возможность анализировать данные, получать ответы не только на вопросы из разряда «Что здесь находится?», но и «Почему здесь это находится?», необходимо задействовать пространственное, ассоциативное мышление [41]. Для решения этих задач и используется виртуальное окружение.
Виртуальное окружение — это технология человеко-машинного взаимодействия, которая обеспечивает погружение пользователя в виртуальную реальность и предоставляет естественный интуитивный интерфейс для взаимодействия с трехмерной средой [111].
Виртуальная реальность — это искусственно созданная трехмерная среда, которая передаётся человеку через органы чувств: зрение, слух, осязание. Для создания виртуальной реальности применяются сложные технические средства, системы виртуального окружения. Пользователь может воздействовать на трехмерную среду, которая обновляется в реальном времени.
Часто термины «виртуальная реальность» и «виртуальное окружение» взаимозаменяемы, и являются почти синонимами.
Помимо синтеза виртуальной среды важным является взаимодействие с виртуальным глобусом и данными на нем. Под взаимодействием понимается следующее: перемещение в пространстве виртуального глобуса: режим полета, режим прогулки, подземное перемещение; а также воздействие на глобус и объекты на глобусе разными способами, включая графический интерфейс пользователя (например, переключение видимости слоев, отдельных объектов, переключение режимов визуализации глобуса).
Разработки в области взаимодействия в виртуальном окружении ведутся уже больше 20 лет. Например, работы [112, 113] описывают разные способы реализации такого взаимодействия. За последние годы появилось новое поколение аппаратных средств, которые позволили удешевить разработку систем виртуальной реальности. Это привело к появлению новых работ, включающих разработки по взаимодействию с глобусом. Например, в работе [114] описывается управление глобусом с помощью жестов руками. А в работе [41] — взаимодействие с помощью сенсорной панели с поддержкой множественных касаний (multi-touch). В работе [115] описывается взаимодействие с геопространственными данными в виртуальной реальности в рамках археологической реконструкции.
В параграфе 4.1 будет рассмотрен программный комплекс, который включает реализацию алгоритмов, описанных в главах 2 и 3, обеспечивает стереоскопическую визуализацию и взаимодействие с глобусом и данными в виртуальном окружении. В параграфе 4.2 рассмотрена стереоскопическая визуализация виртуального глобуса. В параграфе 4.3 описываются подходы к навигации (перемещению в 3D-пространстве), естественному взаимодействию, взаимодействию через графический интерфейс пользователя, взаимодействию с помощью мыши.
4.1. Программный комплекс
Программный комплекс для визуализации виртуального глобуса и 3D-данных на глобусе в стереоскопическом режиме реализует варианты визуализации виртуального глобуса, описанные во второй главе, алгоритмы рендеринга 3D-данных, описанные в третьей главе, поддерживает различные стерео-режимы, режимы навигации и взаимодействие с 3D-данными.
Аппаратное обеспечение. Программный комплекс может работать на современном аппаратном обеспечении, использовать 3D-мониторы, джойстики с 6ю-степенями свободы, сенсор Kinect. Подробнее это будет рассмотрено в параграфах 4.2 и 4.3. Пример аппаратного обеспечения показан на рис. 4.1. Спецификация оборудования приведена в приложении Г. Указанные комплектующие доступны на рынке и имеют небольшую цену.
 |
| Рис. 4.46. Пример аппаратной конфигурации |
Зависимости. Программный комплекс использует в своей работе различные сторонние библиотеки. Диаграмма зависимостей между используемыми библиотеками показана на рисунке 4.2.
 |
| Рис. 4.47. Зависимости от сторонних библиотек |
В основе комплекса лежит графический инструментарий 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 (вид) управляет визуализацией одной трехмерной сценой. Это позволяет переключаться между видами во время работы программы. Например, один вид может содержать глобус, а другой вид — только некий набор 3D-данных без глобуса, как на рисунке 4.20, либо другой глобус с другими данными.
Вид включает одну (в моно-режиме) или две (в стерео-режиме) виртуальных камер (класс Camera), а также экземпляр класса CameraManipulator для навигации по сцене. С каждой камерой связан графический контекст (класс GraphicsContext), в который и происходит отрисовка.
Класс StereoViewer произведен от класса CompositeViewer из фреймворка OpenSceneGraph и играет роль фасада, который отвечает за визуализацию. Он запускает внутри себя цикл отрисовки и содержит коллекцию видов (View), позволяет их создавать и настраивать стерео-режимы. StereoViewer расширяет функциональность базового класса единообразной поддержкой стереовизуализации для разных стереорежимов. Для трекинга головы с помощью сенсора Kinect он обращается к классу KinectAdapter.
 |
| Рис. 4.48. Основные классы ядра программного комплекса |
Класс ViewManager занимается настройкой, высокоуровневым управлением трехмерной сценой и содержит ряд инструментов для работы со сценой. Picker – позволяет взаимодействовать с объектами сцены с помощью инструмента «виртуальная лазерная указка», LaserPointer – рисует луч указки, SceneRoot – настраивает графические эффекты, EarthManager – управляет режимами визуализации глобуса (класс MapNode) и атмосферы (класс SkyNode).
Для навигации используются несколько классов, производных от CameraManipulator. Они рассчитывают матрицу вида на основе входных данных от органов управления: мыши, клавиатуры, джойстика. Разные классы реализуют разные режимы навигации. Они могут использовать данные от устройств ввода (класс Device), таких как джойстик SpaceNavigator (класс SpaceNavDevice).
Для управления трехмерной сценой через графический интерфейс используется класс MainWindow, производный от QMainWindow.
Подключаемые модули. На базе ядра программного комплекса можно разрабатывать производные приложения или дополнительные подключаемые модули для решения конкретных практических задач. Каждый подключаемый модуль содержится в своей динамически подключаемой библиотеке dll. Типовая схема подключаемого модуля показана на рис. 4.4.
В ядре объявлен интерфейсный класс IPluginBase, от которого должны наследоваться классы-загрузчики подключаемых модулей. При загрузке dll с модулем в память создаются экземпляры этих классов и помещаются в PluginRegistry, который реализован с помощью шаблона проектирования «Синглтон».
Загрузчик — компонент, который вызывается из ядра программного комплекса (через PluginRegistry) и настраивает модель и контроллер для дальнейшей работы.
Модель — компонент, который отвечает за загрузку полезных данных, создание 3D-объектов и подключение их к трехмерной сцене, и выполнение над ними операций;
Контроллер — компонент, который создает графический интерфейс на основе фреймворка Qt (класс Widget) и вставляет его в главное окно. При взаимодействии пользователя с виджетами контроллер посылает команды модели. Дополнительно может быть класс EventHandler для обработки событий клавиатуры.
В рамках комплекса может быть подключено любое количество таких модулей. Программный комплекс можно в дальнейшем неограниченно расширять и применять для визуализации различных типов геопространственных данных.
 |
| Рис. 4.49. Основные классы подключаемого модуля |
Далее более подробно будут рассмотрены 3 аспекта: поддержка стереоскопической визуализации, режимы навигации и взаимодействие с данными.
4.2. Стереоскопическая визуализация
Стереоскопическая визуализация — это вид визуализации, при котором синтезируются 2 изображения с 2х виртуальных камер, одно изображение — для левого глаза, другое — для правого. Это позволяет воспринимать форму, размер и расстояние до объектов. Стереовизуализация — основное средство создания виртуальной реальности.
Человек использует разные факторы для определения глубины до предметов. Ряд из них доступен для одного глаза: размеры предмета, тени, перекрытия предметов, априорные знания.
Три фактора доступны только при бинокулярном зрении, т.е. при использовании 2-х глаз [122]:
- бинокулярная диспарантность — основана на параллаксе (изображения сдвинуты друг относительно друга из-за расстояния между глазами);
- вергенция — вращение глазных яблок, чтобы сфокусироваться на предмете;
- аккомодация — изменение кривизны хрусталика, необходимое, чтобы сфокусироваться на предмете.
В современных системах виртуального окружения стереоскопический эффект достигается за счет использования первых двух факторов: бинокулярной диспарантности и вергенции.
Первые системы виртуального окружения возникли более 30 лет назад. Они были громоздкие и дорогостоящие и применялись для узких задач. Однако последние годы, благодаря росту производительности персональных компьютеров, эта тема снова начала активно развиваться. Здесь нужно упомянуть Джеймса Кэмерона, который снял фильм Аватар в стерео в 2009 году и тем самым популяризировал идею стереовизуализации [123]. Фирма NVIDIA выпустила недорогие затворные очки 3d vision, а производители мониторов выпустили совместимые мониторы с частотой 120Гц [116].
4.2.1 Технологии стереовизуализации
Для обеспечения стереоскопической визуализации необходимо взаимодействие 3х компонентов: приложение, которая генерирует изображения для 2х глаз; видеокарты, которая может поддерживать специальный режим для стерео; системы отображения (включает в себя и очки).
В настоящее время существует множество систем отображений, которые применяют различные технологии для разделения изображений для 2х глаз. Кратко перечислим системы и соответствующие технологии:
- Анаглиф: простейшая и наиболее примитивная технология, с плохим качеством восприятия. К изображениям для разных глаз применяются программные цветофильтры: к одному — синий, к другому — красный, после чего 2 изображения объединяются в одно, которое и выводится с помощью самого обычного монитора или проектора. Для просмотра стереоизображения нужно иметь очки со встроенными в них цветофильтрами [124, 125].
- 2х-проекторная система с использованием поляризации: используется горизонтальная стереопара, левая половина которой отображается одним проектором, а правая — другим. Для разделения изображений используются поляризационные фильтры с линейной или круговой поляризацией, фильтры устанавливаются на очки и на проекторы [111].
- Черезстрочная поляризация: используется монитор или телевизор, пиксели четных строк которого имеют одну поляризацию, а пиксели нечетных строк — другую. Поэтому изображение, подаваемое на монитор, должно быть составлено из двух изображений: четные строки от одного изображения, а нечетные — от другого. Необходимы очки с поляризационными фильтрами.
- Затворное стерео: изображение выводится на монитор или проектор с частотой 120Гц, при этом очки синхронно с монитором попеременно открывают и закрывают глаза.
- Инфитек: используется спектральное разделение каналов. В компьютере любой цвет задается комбинацией 3х базовых цветов: красного, зеленого и синего. Но при выводе каждому из этих цветов соответствует диапазон длин волн. Для левого и правого глаз выводятся немного отличающиеся длины волн. Глаз отличия не воспринимает, но разница длин волн позволяет создать фильтры, которые устанавливаются на очки и на выходе из проектора [126].
- Шлем виртуальной реальности, в котором каждому глазу соответствует свой мини-экран.
Некоторые стереорежимы могут работать без специальной поддержки видеокарты: анаглиф, поляризационные системы. Изображение, сгенерированное стандартным способом, просто посылается на систему отображения. Другие режимы — затворное стерео и инфитек — требуют специального режима работы видеокарты: квадробуфер, который доступен только на дорогих профессиональных видеокартах Nvidia Quadro и AMD FirePro [127, 128].
Иногда также применяются термины «пассивное стерео» и «активное стерео». Под пассивным стерео понимается система, когда изображения из 2х глаз выводятся одновременно. Обычно это системы, основанные на поляризации. Под активным стерео понимается система, когда изображения для 2х выводятся по очереди, с частотой 120Гц. Сюда же относятся затворное стерео и инфитек, хотя инфитек использует пассивные очки.
4.2.2. Настройка стереоэффекта в программном комплексе
Поддержать стереоэффект на уровне приложения можно несколькими способами. В работе [129] описаны несколько подходов:
- используется одна виртуальная камера, которая рендерится в 2 прохода. После выполнения проекционного преобразования в вершинном шейдере усеченные координаты сдвигаются влево или вправо. Этот вариант также используется в стереодрайвере NVidia. Минус подхода — некорректное отсечение невидимых объектов (culling);
- используется одна виртуальная камера, которая рендерится в 2 прохода. В каждом проходе используются свои модифицированные матрицы вида и проекции. Это позволяет организовать корректное отсечение;
- используются две виртуальные камеры. Каждая камера использует свои матрицы вида и проекции.
Если приложение изначально разрабатывалось без учета стереоскопичекой визуализации, то для быстрого подключения стерео можно использовать 1-й или 2-й варианты. Но при разработке новых приложений рекомендуется использовать 3-й вариант с двумя виртуальными камерами, как более гибкий. Он позволяет поддержать различные стерео-режимы единообразным способом.
С точки зрения приложения можно выделить три основных стерео-режима, которые отличаются настройками виртуальных камер.
- горизонтальная стереопара (side-by-side): выходное изображение состоит из двух половин, составленных рядом. Левая половина содержит изображение для левого глаза, а правая половина — для правого глаза;
- черезстрочное стерео: четные строки выходного изображения — это строки изображения для левого глаза, а нечетные строки — для правого глаза;
- квадробуфер: основан на использовании специального режима видеокарты, при котором в видеопамяти отдельно создается буфер для левого глаза и отдельно для правого. Каждый из них в свою очередь имеет задний буфер (туда идет рендеринг) и передний буфер (он выводится на экран). Отсюда и название режима.
Для настройки режимов в приложении нужно следовать следующим рекомендациям. Пусть 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.
 |
| Рис. 4.50. Виртуальный глобус в режиме черезстрочного стерео |
4.2.3. Учет разброса масштабов для виртуального глобуса в программном комплексе
Математика стереоэффекта описана в приложении В, приведены формулы расчета матриц вида и проекции для виртуальных камер. В случае, если масштаб сцены слишком маленький или слишком большой по сравнению с реальными размерами системы отображения, то необходимо применять параметр «расстояние схождения» (fusion distance) для масштабирования виртуальной системы отображения.
Но в случае виртуального глобуса возникает осложнение: большой разброс масштабов. Мы хотим видеть глобус «объемным» из космоса и хотим ощущать «объем» для объектов у поверхности глобуса и для космических аппаратов на орбите. Для этого необходимо динамически изменять расстояние схождения в зависимости от положения наблюдателя.
Существует два основных варианта вычисления расстояния схождения:
- брать расстояние от камеры до точки на рельефе вдоль луча зрения;
- брать высоту камеры над рельефом.
Было проведено сравнение обоих вариантов. Субъективно второй вариант показал лучшее качество восприятия стереоэффекта особенно в гористом рельефе.
Отдельная проблема возникает, если нужно приблизиться к объекту, приподнятому над рельефом, например к космическому аппарату (спутнику), летящему по орбите. В этом случае мы не сможем увидеть его вблизи: он будет слишком маленьким по сравнению с расстоянием между камерами. Поэтому нужно брать минимальное расстояние схождения:
  , | (4.27) |
При приближении к поверхности формулу необходимо корректировать. Пусть ed — высота камеры над рельефом (earth distance). Если 
, то на вершинах небоскребов будет ощущаться сильное расхождение изображений. Для отдельных зданий можно реализовать собственное вычисление 
и применять по аналогии с формулой для спутников. Либо можно зафиксировать значение 
на высотах ниже предельной высоты:
  , | (4.28) |
В этом случае на высотах меньше 
, а значит 
, что соответствует реальным параметрам виртуальных камер. 
можно взять, например, 100 м.
4.3. Навигация и взаимодействие
4.3.1. Навигация
Навигация — это управление перемещением виртуальной камеры по трехмерной сцене. Управление может осуществляться от клавиатуры, мышки, джойстика или другими способами. Существует несколько моделей движения. Они описаны в работах [112, 113]. В случае виртуального глобуса есть свои особенности.
Обзор моделей движения
Конечным результатом навигации является матрица вида, которая содержит положение и ориентацию виртуальной камеры. Матрица вида выполняет преобразование из мировой в видовую систему координат. Центр видовой системы координат связан с центром камеры. Камера смотрит вдоль отрицательного направления оси Z. Ось X направлена вправо, ось Y — вверх [71].
Матрица вида 
переводит координаты вершины из мировой СК в видовую СК. Обратную ей матрицу 
можно назвать матрицей наблюдателя, т.к. она описывает положение наблюдателя (камеры) в мировой СК. В дальнейшем будет удобно работать именно с 
. Каждый кадр необходимо на основе данных с устройств ввода обновлять значение 
и затем получать 
.
Все модели движения можно разбить на два класса: центр вращения (pivot) совпадает с камерой или центр вращения вынесен вперед.
1. В модели, когда центр вращения совпадает с камерой, состояние камеры определяется 2мя параметрами: вектор положения центра камеры в мировой СК (и соответствующая ему матрица сдвига) и кватернион вращения (и соответствующая ему матрица вращения). Оба параметра изменяются независимо. Итоговая матрица вычисляется так:
 | (4.29) |
Это можно представить следующим образом: сначала камера находится в начале координат (в видовой СК), затем мы вращаем камеру и сдвигаем в нужную точку.
2. В модели с вынесенным вперед центром вращения состояние камеры определяется 3мя параметрами: вектор положения центра вращения (и соответствующая ему матрица сдвига), кватернион вращения относительно центра вращения (и соответствующая ему матрица вращения) и расстояние от центра вращения до камеры (ему соответствует матрица сдвига по оси Z). В случае глобуса центр вращения естественным образом должен находиться на поверхности глобуса. Итоговая матрица вычисляется так:
 | (4.30) |
Это можно представить следующим образом: сначала камера находится в начале координат (в видовой СК), затем мы отодвигаем камеру на расстояние 
по оси Z, затем вращаем камеру вокруг начала координат, затем двигаем начало координат (центр вращения) в заданную точку в мировой СК.
В случае глобуса удобнее использовать немного другой подход. В точке вращения вводится локальная система координат (рис. 4.6) и формируется матрица перевода в мировую систему координат 
. А кватернион вращения задается в этой локальной системе координат. Тогда итоговая матрица будет выглядеть так:
 | (4.31) |
Это показано на рисунке 4.7.
 |
| Рис. 4.51. Локальная система координат на глобусе |
Каждая из этих двух моделей имеет свои преимущества и недостатки. Можно провести следующие ассоциации.
В случае модели, когда центр вращения совпадает с камерой, пользователь ощущает себя персонажем в виртуальном мире. Он может перемещаться (двигать вектор положения) и вращать головой по сторонам (менять кватернион вращения).
В модели, когда центр вращения вынесен, пользователь ощущает себя исследователем, который крутит в руках объект. При использовании этой модели может сложиться впечатление, что не пользователь двигается вокруг объекта, а пользователь неподвижен и двигает объект.
 |
| Рис. 4.52. Задание положения камеры |
Преимуществом модели с вынесенным центром вращения является возможность одним движением мыши облететь вокруг объекта на поверхности глобуса. При этом сначала центр вращения сдвигается в точку расположения объекта, и затем мышкой меняется только матрица вращения.
Но модель, когда центр вращения совпадает с камерой, является более гибкой. Она позволяет реализовать дополнительно режим прогулки по рельефу, когда камера зафиксирована над рельефом на заданной высоте, и режим подземного перемещения.
При использовании джойстика с 6-ю степенями свободы также более удобным является вариант, когда отдельно задается положение и отдельно вращение. Три степени свободы джойстика соответствуют перемещению камеры в мировой СК. Другие три степени вращения — соответствуют вращению камеры. При использовании такого джойстика удобна ассоциация именно с поворотами головы.
Комбинированный вариант между двумя моделями движения реализован в Google Earth. Для задания положения камеры центр вращения не используется, но при вращении он динамически вычисляется в месте клика мышкой по рельефу, а не задан принудительно. Т.е. камера вращается вокруг точки, куда кликнула мышка.
Реализация в программном комплексе
Сдвиг камеры в мировой СК в каждый момент времени можно разложить по 3м взаимно перпендикулярным осям, которые образуют локальную СК (рис. 4.6). Центр локальной СК совпадает с текущим положением камеры. Два вектора направлены «вправо» и «вверх» в тангенциальной плоскости. Третий вектор — это вектор нормали к эллипсоиду в этой точке.
При движении в тангенциальной плоскости расстояние до центра глобуса необходимо поддерживать постоянным. Также необходимо корректировать вращение камеры, чтобы оно оставалось постоянным в локальной системе координат.
Вращение камеры можно реализовать 2мя основными способами: «ведение» и «взаимодействие». В режиме «ведения» камера поворачивается вслед за мышкой. Если мышка движется влево, то и камера движется влево. При этом кусор мыши делается невидимым. В режиме «взаимодействие» мышка не оказывает влияние на камеру. Можно выбрать любой объект на экране и нажать на него.
Управление от клавиатуры и мыши описано в таблице 1. Однако рекомендуется использовать джойстик с 6-ю степенями свободы, которые непосредственно отображаются на перемещение камеры.
Каждый кадр необходимо пускать из камеры луч вниз по нормали к эллипсоиду для определения точки пересечения с рельефом и вычисления расстояния до рельефа. Это расстояние — важная переменная, которая используется для нескольких задач. Например, скорость движения удобно привязать к высоте над рельефом. Эмпирически подобран коэффициент пропорциональности 1,5.
  , | (4.32) |
где 
– минимальная скорость, которую можно положить 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) [41]. Такие экраны с помощью движений нескольких пальцев по экрану позволяеют двигать, вращать и масштабировать двумерные изображения.
Дальнейшее развитие этой технологии связано с появлением в конце 2010 года устройства Microsoft Kinect, основанного на технологиях израильской компании PrimeSense [121]. Kinect содержит несколько сенсоров: сенсор глубины, цветную камеру и набор из 4-х микрофонов (рис. 4.8). Сенсор глубины состоит из двух частей: эмиттера, который излучает сигнал в инфракрасном диапазоне; и инфракрасной камеры, для определения отраженного инфракрасного света.
 |
| Рис. 4.53. Строение устройства Microsoft Kinect |
На вход компьютеру поступает два видеопотока (цветной и с картой глубин) и звук из микрофонов. Специальное программное обеспечение позволяет выделить на карте глубин точки, принадлежащие разным частям тела человек, и построить на основе этих данных скелет [132, 133]. Изменение положения костей скелета во времени можно использовать для выделения жестов и реакции на них. Сигнал с микрофонов очищается от фонового звука и может использоваться для распознавания речи. Система позволяет одновременно определять скелеты 2х человек в кадре и разделять общий звуковой сигнал по голосам отдельных людей.
Для работы с Kinect существует два инструментария для разработки: официальный SDK от компании Microsoft, который работает только под Windows, и неофициальный кроссплатформенный OpenNI, поддерживающий и другие аналогичные сенсоры [134].
В настоящее время наиболее очевидное и популярное применение Kinect — видеоигры. Перспективно использовать его в научных приложениях для более удобного и интуитивного управления приложением для визуального анализа. Появились работы, посвященные управлению виртуальным глобусом с помощью жестов [114, 135].
Недавно было анонсировано устройство Leap Motion, которое предназначено для высокоточного отслеживания пальцев рук, что позволит двигать курсор мыши пальцами и нажимать на кнопки графического интерфейса легким жестом указательного пальца в воздухе [136]. В версию Google Earth 7.1 была добавлена поддержка Leap Motion [137].
В целом задача распознавания жестов и голосового управления выходит за рамки данной диссертации. Однако в теме естественного взаимодействия можно выделить задачу использования трекинга головы в виртуальном окружении.
В схеме, описанной в приложении В, предполагалось, что голова наблюдателя фиксирована относительно экрана. Однако в реальности это не так. Даже если наблюдатель сидит четко перед экраном, его голова может отклоняться в разные стороны.
Трекинг головы (и в том числе трекинг глаз) позволяет скорректировать параметры виртуальных камер в соответствии с реальным положением глаз наблюдателя относительно экрана. Это способствует более глубокому «погружению» и реалистичному восприятию объема. Основной минус трекинга головы — изображение на экране становится адаптированным только под одного наблюдателя. Соседним зрителям будет некомфортно смотреть на экран. Поэтому трекинг головы предназначается в первую очередь для индивидуального использования.
Системы трекинга головы существуют и разрабатываются довольно давно. Стоимость таких системы может достигать тысяч долларов и предназначены они для использования вместе с дорогостоящими системами визуализации [138].
Поддержка Kinect в программном комплексе
В программном комплексе используется Microsoft Kinect для организации простого трекинга в рамках автоматизированного рабочего места. Конечно, точность трекинга оставляет желать лучшего [133]. Но плюсами устройства являются его дешевизна и отсутствие необходимости в долгой настройке. Устройство нужно разместить прямо под монитором и направить на пользователя (рис. 4.9).
 |
| Рис. 4.54. Расположение монитора, Кинекта и пользователя |
Программное обеспечение для связи с Кинектом позволяет получить координаты 20 вершин скелета, одна из которых относится к голове (рис. 4.10). Зная координаты головы, можно получить координаты двух глаз. Существуют алгоритмы для определения поворотов головы. Существует библиотека Face Tracking для построения полигональной сетки лица, что позволяет более точно определить координаты глаз [139].
Зная координаты глаз, можно вычислить параметры виртуальных камер: их матрицы вида и проекции. Изначально координаты находятся в системе координат Кинекта. На рисунке 4.9 показан ось Z этой системы координат. Она выходит из Кинекта вдоль оптической оси датчика глубины.
 |
| Рис. 4.55. Вершины скелета |
Связь между всеми системами координат можно изобразить в виде графа на рисунке 4.11. Удобно считать, что модуль навигации, описанный в параграфе 4.1, воздействует на условную точку, которая закреплена относительно экрана и находится перед ним на расстоянии sd. Будем называть эту точку стереоцентром (рис. 4.12). Кинект зафиксирован относительно стереоцентра. Его положение в системе координат стереоцентра задается матрицей 
. Положение глаз в системе координат кинекта 
и 
. Итого матрицы вида для левого и правого глаз вычисляются по формулам:
 | (4.33) |
 | (4.34) |
Матрицы проекции для виртуальных камер можно задать через параметры left, right, bottom, top, znear, zfar:
  , | (4.35) |
  , | (4.36) |
  , | (4.37) |
  , | (4.38) |
где 
— сдвиг глаза относительно стереоцентра, sw — ширина экрана, а sh — высота экрана.
 |
| Рис. 4.56. Связь систем координат |
Эти параметры необходимо подставить в формулу вычисления матрицы проекции [71]:
  , | (4.39) |
4.3.3. Графический интерфейс пользователя
При работе с данными важной частью приложения является графический интерфейс пользователя (Graphical User Interface, GUI). Графический интерфейс — это совокупность, так называемых, виджетов, графических элементов управления, расположенных на экране. Примеры виджетов: кнопки, переключатели, ползунки, панели, меню.
 |
| Рис. 4.57. Виртуальная камера относительно центра |
Существует множество программных библиотек, которые существуют и применяются уже многие годы. Однако в случае стереоскопической визуализации возникает ряд технических проблем. В данном параграфе эти проблемы будут рассмотрены и будет приведен набор рекомендаций по реализации графического интерфейса.
Все графические интерфейсы можно разделить на два типа: внешний и встроенный.
Внешний графический интерфейс задает «каркас» окна приложения. Сюда входит рамка окна, верхняя строка меню, панели с виджетами по бокам. А графическое окно представляет собой лишь прямоугольный виджет, встроенный внутрь окна приложения наравне с другими виджетами (рис. 4.13). Примеры фреймворков для реализации внешнего интерфейса: Qt, WPF, MFC, wxWidgets. Такой интерфейс применяется в основном для приложений, рассчитанных на работу и взаимодействие с данными, анализ данных.
Внешний графический интерфейс хорошо сочетается со стереорежимами: черезстрочное стерео и квадробуфер, т.к. эти режимы применимы к любой прямоугольной области на экране. Однако режим горизонтальной стеропары не совместим с внешним графическим интерфейсом. Приложение в этом режиме принципиально является полноэкранным, и все виджеты должны дублироваться на двух половинах экрана. Однако существующие фреймворки не рассчитаны на такое применение.
 |
| Рис. 4.58. Внешний интерфейс на основе фреймворка Qt |
Встроенный графический интерфейс находится внутри графического окна и является 3D-объектом наравне с другими объектами трехмерной сцены (рис. 4.14). Примеры фреймворков для реализации встроенного интерфейса: Scaleform, CEGUI, MyGUI. Такой интерфейс применяется в основном в компьютерных играх, симуляторах и тренажерах.
Встроенный интерфейс поддерживается стереорежимами: черезстрочное стерео и квадробуфер. Режим горизонтальной стереопары технически возможен, но не все популярные фреймворки для создания графического интерфейса его поддерживают.
Но помимо этого имеется проблема восприятия встроенного интерфейса в режиме стереовизуализации. Встроенный интерфейс является 3D-объектом в виртуальной сцене и может пересекаться геометрически с другими объектами. В монорежиме традиционно это решается путем принудительного рендеринга интерфейса поверх основной сцены (с отключенным буфером глубины).
В случае стереорежима такой подход приводит к визуальному дискомфорту и нарушению стереовосприятия. Действительно: трехмерный рельеф или другие объекты «выдвигаются» из экрана, а меню закрывает часть рельефа и рисуется в плоскости экрана. Получается, что глаз не понимает, на что ему фокусироваться: на ближний объект (рельеф) или на более дальний объект (интерфейс), который разрывает ближний объект.
 |
| Рис. 4.59. Встроенный интерфейс на основе фреймворка CEGUI |
Компромиссный вариант — сначала рендерить интерфейс в плоскости экрана, а затем поверх него трехмерный рельеф с включенной прозрачностью и смешиванием цветов. Визуальный дискомфорт меньше, чем в предыдущем случае, но все равно присутствует.
Радикальный вариант — разрешить пересечение рельефа с интерфейсом. В этом случае возможна ситуация, когда рельеф полностью закрывает часть интерфейса, и его функции становятся недоступными.
Благодаря стереовизуализации открывается еще одна возможность — «выдвинуть» интерфейс из плоскости экрана вперед на такое расстояние, чтобы оно не пересекалось с рельефом. Но при этом возникает сразу 2 новые проблемы. Во-первых, если выдвинуть интерфейс слишком далеко из экрана, то глазам будет трудно на нем сфокусироваться, и глаза станут быстро уставать. Во-вторых, мышка движется в плоскости экрана, поэтому при фокусировке глаз на интерфейсе, курсор мыши начнет раздваиваться и нажатие на виджеты будет затруднено.
Итого есть четыре основных варианта взаимного рендеринга интерфейса и других объектов в едином трехмерном пространстве:
- интерфейс принудительно рендерится поверх других объектов;
- цвет выступающих объектов смешивается с цветом интерфейса (полупрозрачный режим);
- объекты рендерится поверх меню без смешивания цветов;
- меню выдвигается вперед из плоскости экрана.
Ни один из этих вариантов не является идеальным. Поэтому создавать сложный встроенный интерфейс нужно осторожно случае стереовизуализации. Полностью отказаться от него не всегда возможно. Поэтому учитывать несколько рекомендаций: 1) интерфейс должен находиться в плоскости экрана; 2) желательно, чтобы интерфейс был прижат к верхней границе экрана, в крайнем случае — к левой или правой, т.к. трехмерный рельеф обычно выдвигается из нижней части экрана.
4.3.4. Виртуальная лазерная указка
Помимо взаимодействия с графическим интерфейсом пользователю часто необходимо взаимодействие с самими объектами трехмерной сцены. Типовой пример: клик мышкой по объекту. После клика происходит какое-нибудь действие с объектом. В моно-режиме определение, по какому объекту сцены был произведен клик, происходит следующим образом. Из камеры через точку на виртуальном экране, на которую указывает курсор мыши, пускается луч в трехмерную сцены. Происходит проход по графу сцены и определение пересечения луча с конкретным треугольником (рис. 4.15).
В случае стереовизуализации ситуация усложняется. Появляется 3 возможности пускания луча: из двух виртуальных камер или из средней точки (рис. 4.16). Из соображений симметрии кажется, что пускать луч нужно из средней точки. Однако при этом будет не очевидно, по какому объекту производится клик. Видно, что за экраном лучи расходятся. Если объект на пути среднего луча находится далеко от экрана, из виртуальных камер может показаться, что мышка вообще не указывает на объект. Если фокусироваться на объекте, то курсор мыши на экране раздваивается, а если фокусироваться на курсоре — то объект.
 |
| Рис. 4.60. Луч из камеры через курсор мыши на экране |
 |
| Рис. 4.61. Лучи из разных виртуальных камер через курсор мыши на экране |
Поэтому в рамках программного комплекса предлагается инструмент «Виртуальная лазерная указка». Необходимо отключить отображение курсора мыши на экране. При этом пользователь продолжает двигать невидимый курсор по экрану. Из средней точки через невидимый курсор на экране пускается луч на трехмерную сцену и ищется пересечение с объектом (рис. 4.17). В найденной точке отображается маркер — например, сфера или точка радиусом несколько пикселей. Этот маркер — полноценный объект трехмерной сцены, и поэтому его положение на экране для разных виртуальных камер будет разным. Параллакс для маркера будет аналогичным параллаксу объекта, с которым было пересечение луча. Поэтому такой подход не будет вызывать дискомфорта у глаз.
 |
| Рис. 4.62. Использование маркера внутри сцены вместо курсора мыши |
Поиск пересечения луча с объектам должен происходить не по клику, а каждый кадр. Тогда при движении курсора маркер будет плавно двигаться по трехмерной сцене и создавать иллюзию движения курсора мыши. Если пересечение с объектом не найдено, то маркер необходимо отобразить на расстоянии от камеры, которое равно расстоянию до последней точки пересечения. Такой маркер напоминает точку от луча лазерной указки (рис. 4.18).
Дополнительно реализован режим работы указки с включенным лучом указки. Особенностью этого режима является то, что луч не должен исходить из самой камеры, иначе он будет виден как точка на экране. Луч должен исходить из точки, отстоящей немного вниз и вперед от камеры, как будто пользователь держит указку в руке (рис. 4.19). Поиск пересечения с объектами теперь нужно вести с помощью нового луча. Если вести поиск пересечения с помощью луча, исходящего из камеры, то видимый луч указки будет пересекать другие объекты.
Предложенное решение позволяет интуитивно взаимодействовать с объектами в виртуальном пространстве. Пример показан на рис. 4.20. При двойном клике по объекту в левом верхнем углу высвечивается информация об объекте. Аналогично на рис. 4.18 показан маркер без луча, который наведен на иконку. При двойном клике по иконке выполнится привязанное действие.
 |
| Рис. 4.63. Маркер наведен на иконку |
 |
| Рис. 4.64. Вид сбоку: луч лазерной указки исходит из точки вниз и вперед от камеры |
 |
| Рис. 4.65. Пример использования лазерной указки в реальном проекте |
