4.3. Навигация и взаимодействие 4.3.1. Навигация
Навигация — это управление перемещением виртуальной камеры по трехмерной сцене. Управление может осуществляться от клавиатуры, мышки, джойстика или другими способами. Существует несколько моделей движения. Они описаны в работах [112, 113]. В случае виртуального глобуса есть свои особенности.
Обзор моделей движения
Конечным результатом навигации является матрица вида, которая содержит положение и ориентацию виртуальной камеры. Матрица вида выполняет преобразование из мировой в видовую систему координат. Центр видовой системы координат связан с центром камеры. Камера смотрит вдоль отрицательного направления оси Z. Ось X направлена вправо, ось Y — вверх [71].
Матрица вида  переводит координаты вершины из мировой СК в видовую СК. Обратную ей матрицу  можно назвать матрицей наблюдателя, т.к. она описывает положение наблюдателя (камеры) в мировой СК. В дальнейшем будет удобно работать именно с  . Каждый кадр необходимо на основе данных с устройств ввода обновлять значение и затем получать .
Все модели движения можно разбить на два класса: центр вращения (pivot) совпадает с камерой или центр вращения вынесен вперед.
1. В модели, когда центр вращения совпадает с камерой, состояние камеры определяется 2мя параметрами: вектор положения центра камеры в мировой СК (и соответствующая ему матрица сдвига) и кватернион вращения (и соответствующая ему матрица вращения). Оба параметра изменяются независимо. Итоговая матрица вычисляется так:
|
(4.29)
|
Это можно представить следующим образом: сначала камера находится в начале координат (в видовой СК), затем мы вращаем камеру и сдвигаем в нужную точку.
2. В модели с вынесенным вперед центром вращения состояние камеры определяется 3мя параметрами: вектор положения центра вращения (и соответствующая ему матрица сдвига), кватернион вращения относительно центра вращения (и соответствующая ему матрица вращения) и расстояние от центра вращения до камеры (ему соответствует матрица сдвига по оси Z). В случае глобуса центр вращения естественным образом должен находиться на поверхности глобуса. Итоговая матрица вычисляется так:
|
(4.30)
|
Это можно представить следующим образом: сначала камера находится в начале координат (в видовой СК), затем мы отодвигаем камеру на расстояние  по оси Z, затем вращаем камеру вокруг начала координат, затем двигаем начало координат (центр вращения) в заданную точку в мировой СК.
В случае глобуса удобнее использовать немного другой подход. В точке вращения вводится локальная система координат (рис. 4 .51) и формируется матрица перевода в мировую систему координат  . А кватернион вращения задается в этой локальной системе координат. Тогда итоговая матрица будет выглядеть так:
|
(4.31)
|
Это показано на рисунке 4 .52.
|
Рис. 4.51. Локальная система координат на глобусе
|
|
Каждая из этих двух моделей имеет свои преимущества и недостатки. Можно провести следующие ассоциации.
В случае модели, когда центр вращения совпадает с камерой, пользователь ощущает себя персонажем в виртуальном мире. Он может перемещаться (двигать вектор положения) и вращать головой по сторонам (менять кватернион вращения).
В модели, когда центр вращения вынесен, пользователь ощущает себя исследователем, который крутит в руках объект. При использовании этой модели может сложиться впечатление, что не пользователь двигается вокруг объекта, а пользователь неподвижен и двигает объект.
|
Рис. 4.52. Задание положения камеры
|
|
Преимуществом модели с вынесенным центром вращения является возможность одним движением мыши облететь вокруг объекта на поверхности глобуса. При этом сначала центр вращения сдвигается в точку расположения объекта, и затем мышкой меняется только матрица вращения.
Но модель, когда центр вращения совпадает с камерой, является более гибкой. Она позволяет реализовать дополнительно режим прогулки по рельефу, когда камера зафиксирована над рельефом на заданной высоте, и режим подземного перемещения.
При использовании джойстика с 6-ю степенями свободы также более удобным является вариант, когда отдельно задается положение и отдельно вращение. Три степени свободы джойстика соответствуют перемещению камеры в мировой СК. Другие три степени вращения — соответствуют вращению камеры. При использовании такого джойстика удобна ассоциация именно с поворотами головы.
Комбинированный вариант между двумя моделями движения реализован в Google Earth. Для задания положения камеры центр вращения не используется, но при вращении он динамически вычисляется в месте клика мышкой по рельефу, а не задан принудительно. Т.е. камера вращается вокруг точки, куда кликнула мышка.
Реализация в программном комплексе
Сдвиг камеры в мировой СК в каждый момент времени можно разложить по 3м взаимно перпендикулярным осям, которые образуют локальную СК (рис. 4 .51). Центр локальной СК совпадает с текущим положением камеры. Два вектора направлены «вправо» и «вверх» в тангенциальной плоскости. Третий вектор — это вектор нормали к эллипсоиду в этой точке.
При движении в тангенциальной плоскости расстояние до центра глобуса необходимо поддерживать постоянным. Также необходимо корректировать вращение камеры, чтобы оно оставалось постоянным в локальной системе координат.
Вращение камеры можно реализовать 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 .53). Сенсор глубины состоит из двух частей: эмиттера, который излучает сигнал в инфракрасном диапазоне; и инфракрасной камеры, для определения отраженного инфракрасного света.
|
Рис. 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 .54).
|
Рис. 4.54. Расположение монитора, Кинекта и пользователя
|
Программное обеспечение для связи с Кинектом позволяет получить координаты 20 вершин скелета, одна из которых относится к голове (рис. 4 .55). Зная координаты головы, можно получить координаты двух глаз. Существуют алгоритмы для определения поворотов головы. Существует библиотека Face Tracking для построения полигональной сетки лица, что позволяет более точно определить координаты глаз [139].
Зная координаты глаз, можно вычислить параметры виртуальных камер: их матрицы вида и проекции. Изначально координаты находятся в системе координат Кинекта. На рисунке 4 .54 показан ось Z этой системы координат. Она выходит из Кинекта вдоль оптической оси датчика глубины.
|
Рис. 4.55. Вершины скелета
|
|
Связь между всеми системами координат можно изобразить в виде графа на рисунке 4 .56. Удобно считать, что модуль навигации, описанный в параграфе 4.1, воздействует на условную точку, которая закреплена относительно экрана и находится перед ним на расстоянии sd. Будем называть эту точку стереоцентром (рис. 4 .57). Кинект зафиксирован относительно стереоцентра. Его положение в системе координат стереоцентра задается матрицей  . Положение глаз в системе координат кинекта  и  . Итого матрицы вида для левого и правого глаз вычисляются по формулам:
|
(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 .58). Примеры фреймворков для реализации внешнего интерфейса: Qt, WPF, MFC, wxWidgets. Такой интерфейс применяется в основном для приложений, рассчитанных на работу и взаимодействие с данными, анализ данных.
Внешний графический интерфейс хорошо сочетается со стереорежимами: черезстрочное стерео и квадробуфер, т.к. эти режимы применимы к любой прямоугольной области на экране. Однако режим горизонтальной стеропары не совместим с внешним графическим интерфейсом. Приложение в этом режиме принципиально является полноэкранным, и все виджеты должны дублироваться на двух половинах экрана. Однако существующие фреймворки не рассчитаны на такое применение.
|
Рис. 4.58. Внешний интерфейс на основе фреймворка Qt
|
Встроенный графический интерфейс находится внутри графического окна и является 3D-объектом наравне с другими объектами трехмерной сцены (рис. 4 .59). Примеры фреймворков для реализации встроенного интерфейса: Scaleform, CEGUI, MyGUI. Такой интерфейс применяется в основном в компьютерных играх, симуляторах и тренажерах.
Встроенный интерфейс поддерживается стереорежимами: черезстрочное стерео и квадробуфер. Режим горизонтальной стереопары технически возможен, но не все популярные фреймворки для создания графического интерфейса его поддерживают.
Но помимо этого имеется проблема восприятия встроенного интерфейса в режиме стереовизуализации. Встроенный интерфейс является 3D-объектом в виртуальной сцене и может пересекаться геометрически с другими объектами. В монорежиме традиционно это решается путем принудительного рендеринга интерфейса поверх основной сцены (с отключенным буфером глубины).
В случае стереорежима такой подход приводит к визуальному дискомфорту и нарушению стереовосприятия. Действительно: трехмерный рельеф или другие объекты «выдвигаются» из экрана, а меню закрывает часть рельефа и рисуется в плоскости экрана. Получается, что глаз не понимает, на что ему фокусироваться: на ближний объект (рельеф) или на более дальний объект (интерфейс), который разрывает ближний объект.
|
Рис. 4.59. Встроенный интерфейс на основе фреймворка CEGUI
|
|
Компромиссный вариант — сначала рендерить интерфейс в плоскости экрана, а затем поверх него трехмерный рельеф с включенной прозрачностью и смешиванием цветов. Визуальный дискомфорт меньше, чем в предыдущем случае, но все равно присутствует.
Радикальный вариант — разрешить пересечение рельефа с интерфейсом. В этом случае возможна ситуация, когда рельеф полностью закрывает часть интерфейса, и его функции становятся недоступными.
Благодаря стереовизуализации открывается еще одна возможность — «выдвинуть» интерфейс из плоскости экрана вперед на такое расстояние, чтобы оно не пересекалось с рельефом. Но при этом возникает сразу 2 новые проблемы. Во-первых, если выдвинуть интерфейс слишком далеко из экрана, то глазам будет трудно на нем сфокусироваться, и глаза станут быстро уставать. Во-вторых, мышка движется в плоскости экрана, поэтому при фокусировке глаз на интерфейсе, курсор мыши начнет раздваиваться и нажатие на виджеты будет затруднено.
Итого есть четыре основных варианта взаимного рендеринга интерфейса и других объектов в едином трехмерном пространстве:
интерфейс принудительно рендерится поверх других объектов;
цвет выступающих объектов смешивается с цветом интерфейса (полупрозрачный режим);
объекты рендерится поверх меню без смешивания цветов;
меню выдвигается вперед из плоскости экрана.
Ни один из этих вариантов не является идеальным. Поэтому создавать сложный встроенный интерфейс нужно осторожно случае стереовизуализации. Полностью отказаться от него не всегда возможно. Поэтому учитывать несколько рекомендаций: 1) интерфейс должен находиться в плоскости экрана; 2) желательно, чтобы интерфейс был прижат к верхней границе экрана, в крайнем случае — к левой или правой, т.к. трехмерный рельеф обычно выдвигается из нижней части экрана.
4.3.4. Виртуальная лазерная указка
Помимо взаимодействия с графическим интерфейсом пользователю часто необходимо взаимодействие с самими объектами трехмерной сцены. Типовой пример: клик мышкой по объекту. После клика происходит какое-нибудь действие с объектом. В моно-режиме определение, по какому объекту сцены был произведен клик, происходит следующим образом. Из камеры через точку на виртуальном экране, на которую указывает курсор мыши, пускается луч в трехмерную сцены. Происходит проход по графу сцены и определение пересечения луча с конкретным треугольником (рис. 4 .60).
В случае стереовизуализации ситуация усложняется. Появляется 3 возможности пускания луча: из двух виртуальных камер или из средней точки (рис. 4 .61). Из соображений симметрии кажется, что пускать луч нужно из средней точки. Однако при этом будет не очевидно, по какому объекту производится клик. Видно, что за экраном лучи расходятся. Если объект на пути среднего луча находится далеко от экрана, из виртуальных камер может показаться, что мышка вообще не указывает на объект. Если фокусироваться на объекте, то курсор мыши на экране раздваивается, а если фокусироваться на курсоре — то объект.
|
Рис. 4.60. Луч из камеры через курсор мыши на экране
|
|
|
Рис. 4.61. Лучи из разных виртуальных камер через курсор мыши на экране
|
|
Поэтому в рамках программного комплекса предлагается инструмент «Виртуальная лазерная указка». Необходимо отключить отображение курсора мыши на экране. При этом пользователь продолжает двигать невидимый курсор по экрану. Из средней точки через невидимый курсор на экране пускается луч на трехмерную сцену и ищется пересечение с объектом (рис. 4 .62). В найденной точке отображается маркер — например, сфера или точка радиусом несколько пикселей. Этот маркер — полноценный объект трехмерной сцены, и поэтому его положение на экране для разных виртуальных камер будет разным. Параллакс для маркера будет аналогичным параллаксу объекта, с которым было пересечение луча. Поэтому такой подход не будет вызывать дискомфорта у глаз.
|
Рис. 4.62. Использование маркера внутри сцены вместо курсора мыши
|
|
Поиск пересечения луча с объектам должен происходить не по клику, а каждый кадр. Тогда при движении курсора маркер будет плавно двигаться по трехмерной сцене и создавать иллюзию движения курсора мыши. Если пересечение с объектом не найдено, то маркер необходимо отобразить на расстоянии от камеры, которое равно расстоянию до последней точки пересечения. Такой маркер напоминает точку от луча лазерной указки (рис. 4 .63).
Дополнительно реализован режим работы указки с включенным лучом указки. Особенностью этого режима является то, что луч не должен исходить из самой камеры, иначе он будет виден как точка на экране. Луч должен исходить из точки, отстоящей немного вниз и вперед от камеры, как будто пользователь держит указку в руке (рис. 4 .64). Поиск пересечения с объектами теперь нужно вести с помощью нового луча. Если вести поиск пересечения с помощью луча, исходящего из камеры, то видимый луч указки будет пересекать другие объекты.
Предложенное решение позволяет интуитивно взаимодействовать с объектами в виртуальном пространстве. Пример показан на рис. 4 .65. При двойном клике по объекту в левом верхнем углу высвечивается информация об объекте. Аналогично на рис. 4 .63 показан маркер без луча, который наведен на иконку. При двойном клике по иконке выполнится привязанное действие.
|
Рис. 4.63. Маркер наведен на иконку
|
|
|
Рис. 4.64. Вид сбоку: луч лазерной указки исходит из точки вниз и вперед от камеры
|
|
|
Рис. 4.65. Пример использования лазерной указки в реальном проекте
|
| |
