СИНХРОНИЗАЦИЯ ПОГРУЖЕНИЯ В ВИРТУАЛЬНУЮ СРЕДУ СИСТЕМЫ "ГИПЕРВИЗОР"

Актуальные публикации по вопросам философии. Книги, статьи, заметки.

NEW ФИЛОСОФИЯ


ФИЛОСОФИЯ: новые материалы (2024)

Меню для авторов

ФИЛОСОФИЯ: экспорт материалов
Скачать бесплатно! Научная работа на тему СИНХРОНИЗАЦИЯ ПОГРУЖЕНИЯ В ВИРТУАЛЬНУЮ СРЕДУ СИСТЕМЫ "ГИПЕРВИЗОР". Аудитория: ученые, педагоги, деятели науки, работники образования, студенты (18-50). Minsk, Belarus. Research paper. Agreement.

Полезные ссылки

BIBLIOTEKA.BY Беларусь - аэрофотосъемка HIT.BY! Звёздная жизнь


Публикатор:
Опубликовано в библиотеке: 2005-02-21

СИНХРОНИЗАЦИЯ ПОГРУЖЕНИЯ В ВИРТУАЛЬНУЮ СРЕДУ СИСТЕМЫ "ГИПЕРВИЗОР"
Афанасьев В.О., Алешин В.И., Галис Р.М., Саночкин А.С., Томи-лин А.Н.
Рассматривается объектно-ориентированный подход к созданию средств описания и реализации синтеза изображений сложной сцены, на-блюдаемой в движении, одновременно с нескольких точек и в различных ракурсах. Показано, как средства языка С++ позволяют в рамках одной системы легко охватить разнородные подсистемы синтеза, предназна-ченные для синхронного вывода стереоскопических изображений через шлем-дисплеи, мониторы со стробированием стереопар, полиэкраны, па-норамы и т.д., ассоциированные с движущимися объектами.
1. ВВЕДЕНИЕ
Система "Гипервизор" представляет собой подсистему графического интерфейса имитационной модели, получившую самостоятельное развитие в направлении повышения реалистичности синтезируемых изображений на основе применения более мощных технических средств визуализации мо-делируемых процессов (цветные растровые дисплеи высокого разрешения, стереоскопия и т.д.), а также создания математического обеспечения ново-го поколения. Это позволяет постепенно расширить рамки возможностей системы отображения данных моделирования до уровня видеоинтерфейса систем класса "Виртуальная Реальность".
Одно из основных требований к системе отображения состоит в пре-доставлении возможности получения визуальной картины событий, разви-вающихся в виртуальной среде в любой момент времени и при любом за-данном ракурсе и положении наблюдателя.
При этом должна обеспечиваться возможность активного движения наблюдателей (свободное перемещение в виртуальном пространстве) и пассивного движения наблюдателей (движение вместе с заданным объек-том и/или в его системе координат). Кроме этого визуальная обстановка должна выводиться на коллективные средства отображения, которые также могут быть ассоциированы с объектами, совершающими свободное или связанное движение.
Развитие событий в виртуальной среде и движение всех наблюдателей должны быть жестко синхронизированы.
Учитывая эти требования, а также то, что изображение должно быть стереоскопическим, и может одновременно располагаться на экранах с различной кривизной, полиэкранах и т.д., задача синхронного синтеза изо-бражений была рассмотрена как обобщенная задача погружения в про-странство сцены произвольного числа объектов, которые кроме простран-ственного движения выполняют особую функцию – наблюдение.
При определенных требованиях наблюдатели могут образовывать ие-рархические структуры, включающие нескольких наблюдателей, которые при перемещении в пространстве ведут себя как единый объект, а для каж-дого из подобъектов осуществляется синхронная настройка и динамиче-ская корректировка параметров, описывающих зрительные поля, зритель-ные оси и т.п. Такие иерархические объекты могут служить для построения стереоскопических и полиэкранных изображений. Иногда необходимо синхронно получать изображения сцены в различных областях спектра. Для этого, например, можно сформировать объект, состоящий из несколь-ких наблюдателей, имеющих одинаковыми все атрибуты, кроме спек-тральных характеристик объективов.
Список различных задач, которые могут быть поставлены перед сис-темой визуализации, можно было бы продолжить еще. Главное, однако, состоит в том, что при формализованном описании такой системы жела-тельно опираться на методы, позволяющие сделать ее архитектуру откры-той и доступной развитию. К таким методам относятся методы объектно-ориентированного программирования, позволяющие существенно "поднять планку" критического уровня сложности при создании больших много-функциональных систем.
В данной работе излагается подход к построению многоуровневой разветвленной системы визуализации виртуальной среды, использующий возможности объектно-ориентированного языка С++ [1]. Показано, как ме-ханизмы наследования и полиморфизма позволяют просто и эффективно построить сложную разветвленную систему отображения, одновременно и согласованно реализующую различные формы визуального погружения в виртуальную среду, генерируемую имитационной моделью.
2. ОПИСАНИЕ ТРЕХМЕРНЫХ СЦЕН В СИСТЕМЕ "ГИПЕРВИЗОР"
Обмен данными между имитационной моделью и системой визуали-зации трехмерных сцен происходит в соответствии с протоколом, который имел рабочее название DLV-3d (Data Linking with Visualizer in 3d-Space) и получил свое развитие в виде непроцедурного языка. Основными объекта-ми этого протокола являются трехмерная сцена и ее участники (рис. 1).
Трехмерная сцена – это совокупность объектов (участников сцены), которые в каждый момент времени (квант системного времени модели) не-которым образом расположены в трехмерном пространстве. Все участники сцены делятся на три разновидности: актеры, зрители и осветители.
Актеры – это изображаемые объекты, отражающие электромагнитные колебания, распространяющиеся в пространстве сцены. Синтезируются изображения именно актеров, которые представляют собой трехмерные тела, поверхности которых имеют заданные характеристики, описывающие явления отражения, рассеяния, поглощения и т.п. в определенных облас-тях спектра электромагнитных колебаний.
Зрители – это не изображаемые объекты, которые осуществляют функции визуализации, воспринимая отраженные от актеров электромаг-нитные колебания. Эти объекты выполняют построение центральной про-екции части сцены, попадающей в видимый объем.
Осветители – это объекты, которые в принципе могут быть изобра-жены, но их основная функция – излучение электромагнитных колебаний различных спектров.

Рис.1. Состав участников сцены
Термины "свет" и "оптический" используются в широком смысле, то есть светом считается набор любых частот электромагнитных колебаний, вызывающих реакцию датчика на энергию излучения (определенную соот-ветствующим образом, например, как это показано в [3]). Такое допуще-ние позволяет описывать приборы, преобразующие излучение, строго го-воря, не входящее в оптический диапазон (например, инфракрасное или ультрафиолетовое), в видимое излучение и т.д.
Для визуализируемых объектов задаются зависимости оптических ха-рактеристик поверхностей от спектра падающего на них излучения. Зрите-ли имеют характеристики пропускания оптического тракта в зависимости от спектра. В настоящее время в системе оптические характеристики по-верхностей и приборов наблюдения реализованы, в основном, для видимо-го (для усредненного глаза человека) спектра, а для остальных диапазонов установлены заглушки. По умолчанию считается, что излучаемый, прини-маемый, а также рассеиваемый и отражаемый спектры относятся к диапа-зону частот видимого света.
Для описания сцены используется непроцедурный язык, позволяющий идентифицировать участников сцены и задать их местоположение и ориен-тацию в системе координат сцены. Идентификация участников осуществ-ляется при помощи ключевых слов, указывающих на тип участника: ACTOR, VISOR и LIGHT. Для актера дополнительно указывается его вид, выбираемый из словаря готовых конструкций. Каждому участнику при-сваивается уникальное имя и значения пространственных атрибутов (по-ложение и ориентация в некоторой системе координат). Кроме этого для зрителей и осветителей указываются специфические атрибуты, характери-зующие их спектральные характеристики, параметры оптики, растра и ряд других.
Между некоторыми из участников могут быть установлены связи (ас-социации), указывающие на совмещение их в пространстве. Например, ес-ли актер должен иметь собственную систему освещения и визуализации, необходимо описать трех участников типа ACTOR, VISOR и LIGHT, ука-зав их взаимосвязь при помощи ключевых слов associate и имен ассоции-рованных участников. Приведем пример описания сцены при помощи текстового файла test.dlv, управление которой осуществляется по данным из файла, содержащего данные эксперимента, а также из некоторого кана-ла. Смысл объявлений и описаний легко понять по контексту.

test.dlv
{


ACTOR Shuttle_US Columbia
place = link trc.dat rotate = link trc.dat

ACTOR orbiter MIR
place = link trc.dat rotate = link trc.dat

VISOR V1 associated MIR
place = link director.dat rotate = link director.dat

VISOR V2 associated Columbia
place = link director.dat rotate = link director.dat

VISOR V3 free
place = link director.dat rotate = link director.dat

LIGHT sun static
SpectralBand = WHITE
place.x = -1. rotate.x = 0.
place.y = 1. rotate.y = 0.
place.z = -1. rotate.z = 0.
}
В данном примере объявлены два участника типа ACTOR, вида Shuttle_US и MIR, два участника типа VISOR и один осветитель типа LIGHT. Пространственные атрибуты описываются ключами place и rotate, причем актеры Columbia и MIR подключены к области trc.dat, откуда фак-тически поступают данные о пространственных атрибутах. Два наблюдате-ля V1 и V2 связаны с системами координат актеров, но подключены к об-ласти данных director.dat, которые задаются руководителем. Таким обра-зом, для V1 и V2 изображения сцены будут привязаны к местной системе координат актеров Сolumbia и MIR. Кроме этого, задан независимый на-блюдатель V3 типа "зонд", который также подчиняется данным, посту-пающим от руководителя через область director.dat, но его система коор-динат свободна. Все три наблюдателя по умолчанию принимают видимый спектр, не имеют оптических насадок и видят сцену "невооруженным гла-зом", что означает выбор фокусного расстояния, соответствующего мас-штабу изображения на сетчатке усредненного глаза. По умолчанию цен-тральное проецирование осуществляется на картинную плоскость. Освети-тель типа SUN статичен, поэтому его пространственные атрибуты заданы явно: он удален в бесконечности, направление потока задано вектором с неизменной ориентацией, излучает SUN в видимом диапазоне.
Как это видно из примера, язык не предусматривает явного управле-ние сценой, так как фактически это должно происходить извне по посту-пающим телеметрическим и траекторным данным, по данным моделиро-вания, а также из файла с описанием сценария или от программы-эмулятора сценария.
В описании сцены участники ее лишь объявляются и некоторым обра-зом характеризуются. Развитие событий в сцене и возможность управления обеспечивается с помощью ключевого слова link и имен областей данных, в которых производятся транзакции по ходу реальных событий или моде-лирования. Имена областей предварительно должны быть введены в кон-текст описания сцены как файл или канал при помощи SQL-вставки.

Рис. 2. Управление погружением
Несколько иначе, чем для остальных участников сцены, организовано управление объектами типа VISOR, при помощи которых осуществляется визуальное погружение в виртуальную среду. Если объект типа VISOR свя-зан с объектом типа ACTOR, то его движение описывается в двух систе-мах координат: местной системе координат актера и в системе координат сцены. Поэтому при реализации поведения зрителей необходимо отслежи-вать две группы событий: события, связанные с изменением состояния данного актера (носителя наблюдателя), и события связанные с заданием ракурса наблюдения (рис. 2).
Когда источником данных является имитационная модель и (или) ре-альная среда (телеметрия и траекторные данные), то в соответствии с кван-тованием времени обновления изображения виртуальной среды система “Гипервизор” обновляет пространственные атрибуты всех участников вир-туальной сцены на данный момент системного времени. Затем производит-ся корректировка местоположения, ориентации и состояния каждого уча-стника сцены, и далее управление передается драйверу развертки изобра-жения сцены.
Если необходимо получить анимационную последовательность, ис-пользуются данные сценария – файла, в котором содержатся данные о ко-ординатах в динамике. Если объем таких данных является слишком боль-шим, может быть использована программа-эмулятор анимационной после-довательности.
Так как описание сцены основано на непроцедурном языке, для опи-сания можно использовать не только текстовый файл, подобный приведен-ному выше, но и оконный интерфейс для сред MS-Windows или X-Windows, а также и для DOS. В настоящее время для среды MS-Windows 3.XX разработан и адаптируется макет такого интерфейса.
3. ОБРАБОТКА И РЕАЛИЗАЦИЯ ОПИСАНИЯ СЦЕНЫ
Для обработки текста описания сцены и создания сцены по этому опи-санию в оперативной памяти служит объект класса STAGE. Этот объект хранит указатели всех участников сцены, то есть является контейнерным для объектов-участников. Развитие обстановки сцены во времени и погру-жение в сцену как в виртуальную среду осуществляется при помощи мето-дов класса STAGE.
Класс STAGE объявлен следующим образом:

class STAGE{
public:
char StageFileName[33]; // Имя файла описания сцены
FILE* StageFile; // Файл описания сцены
ACTOR* Actor; // Массив актеров
VISOR* Visor; // Массив простых зрителей
HYPER* Hyper; // Массив сложных зрителей
LIGHT* Light; // Массив осветителей
KAMERA* Kamera; // Объект, буферизующий
// изображение
int Nactors, // Число актеров
Nvisors, // Число простых зрителей
Nhypers, // Число сложных зрителей
Nlights; // Число осветитилей

STAGE (); // Конструктор сцены
void Compile (); // Проход по тексту описания
// сцены
void Develop (int, nario*); // Развитие событий в сцене
void Immerse (int, nario*, drcp*);// Погружение в среду сцены
};

Как это видно из текста объявления класса, ключевые слова ACTOR, VISOR и LIGHT языка DLV-3d, одновременно являются именами классов объектов С++, которые создаются компилятором сцены при вызове метода Compile, будучи объявленными при вызове конструктора STAGE().
Метод Develop используется для изменения значений пространствен-ных атрибутов участников в соответствии с данными, поступающими от объекта класса NARIO, который объявляется следующим образом.
class NARIO {
public:
STAGE* Stage; // Развиваемая сцена
FILE* EventPtr; // Поток событий (маневрирование)

NARIO ();
void GetManevr (FILE*); //Прием данных об изменении
// координат
// Перемещение и разворот
void ActorEvent (int, FILE*, ACTOR*); // актеров
void VisorEvent (int, FILE*, VISOR*); // простых зрителей
void HyperEvent (int, FILE*, HYPER*); // сложных зрителей
void LightEvent (int, FILE*, LIGHT*); // осветителей
};
Исходный текст сцены обрабатывается компилятором, который, кроме синтаксического анализа выполняет развертывание сцены: сначала выде-ляет память участникам сцены, затем собирает и размещает в выделенной памяти актеров, зрителей (с предварительной сборкой сложных зрителей) и осветителей. Общее представление о структуре классов, характеризующих участников сцены, можно получить из приводимых ниже фрагментов их объявлений с комментариями.
Типы DEKART и MATRIX представляют собой имена структур, со-держащих поля типа double и описывающих соответственно 3-х компо-нентный вектор в декартовых координатах и 9-ти элементные матрицы вращения в декартовой системе. По соображениям, описанным в [4], про-ективные координаты не применяются.
class ACTOR {
...
UNIT* u; // Массив узлов конструкции
int ActorSize; // Размерность массива узлов
DEKART OO, NC; // Положение центра и вектор
// ориентации
MATRIX GR, GO, DR; // Матрицы вращения
...
ACTOR ();
void Compile (FILE*, FILE*); // Проход по тексту сцены
void Basket (FORMA**, int*, int); // Рекурсивное развертывание
// примитивов
void Move (DEKART, DEKART); // Перемещение и вращение
};
В объявлении класса ACTOR содержится указатель на массив узлов конструкции, имеющих нестандартный тип UNIT, который подробно опи-сан в [5].
class LIGHT { ...
public:
SPCTR Spctr; // Спектральные параметры излучения
DEKART OO, NC; // Положение центра и вектор ориентации
MATRIX GR, GO; // Матрицы вращения
...
LIGHT ();
void Compile (FILE*, FILE*); // Проход по тексту сцены
void Move (DEKART, DEKART); // Перемещение и вращение
void Install (ACTOR*); // Совмещение с системой
// координат актера
};
В объявлении класса LIGHT содержатся переменная класса SPCTR, которая представляет собой структуру, с параметрами спектра излучения (характеристики фильтра) и параметры растра на картинной поверхности (прежде всего, это – размеры пиксела).
Заметим, что в описании сцены отсутствуют явные указания на опти-ческие характеристики материалов, из которых изготовлены актеры, кото-рые в действительности содержатся в базе данных моделей актеров, конст-руируемых отдельно заранее. Описание сцены содержит лишь ссылку (тип и имя актера), которая используется компилятором сцены для развертыва-ния в памяти списка примитивов с атрибутами, где и содержатся все необ-ходимые данные.
Поскольку наблюдатели играют основную роль при погружении в виртуальную среду, а также могут иметь иерархическую структуру, рас-смотрим характеризующие их классы VISOR и HYPER более подробно.
4. ОБЪЕКТЫ КЛАССА VISOR
Этот класс служит для хранения атрибутов, необходимых драйверу развертки изображения при синтезе центральных проекций, а также для преобразования этих атрибутов при перемещениях и поворотах зрителя. Кроме этого, если зритель имеет сложную структуру (то есть фактически состоит из нескольких зрителей, как например, полиэкран или стереокаме-ра), атрибуты класса VISOR подвергаются изменениям при управлении со стороны агрегата HYPER.
Приведем фрагмент объявления класса VISOR.
class VISOR {friend DRCP; // Доступ для драйвера развертки
...
public:
FILE* EventPtr; // Поток событий
DEKART OO, NC; // Положение центра и ориентация
MATRIX GR, GO; // Матрицы вращения
float Focus; // Фокусное расстояние объектива
SPCTR Spctr; // Спектральные параметры объектива
RASTR Rastr; // Параметры растра
...
VISOR ();
void Compile (FILE*, FILE*); // Проход по тексту сцены
void Move (DEKART, DEKART); // Перемещение и вращение
void Install (ACTOR*); // Совмещение с системой
//координат актера
};
Поля OO и NC типа DEKART, а также поля GR и GO типа MATRIX играют ту же роль, что и их синонимы в классах ACTOR и LIGHT, то есть служат для отслеживания перемещений и поворотов в некоторой декарто-вой системе. При этом вектор OO описывает центр проекции, а NC – на-правление главной оптической оси.
Смысл полей, характеризующих оптические параметры объекта класса VISOR, поясняет схема оптической системы, показанная на рис. 3.
При построении изображения используется модель обскуры, в которой точечное отверстие совпадает с центром проекции, но имеется одно отли-чие от классической модели – изображение строится на картинной поверх-ности заданной формы. Изменение формы картинной поверхности и уда-ления от нее центра проекции позволяет при необходимости моделировать заданные оптические эффекты и условия наблюдения.
Форма, размер и удаление апертурной диафрагмы от центра проекции используются для ограничения поля зрения. Вместо удаления апертурной диафрагмы может быть задан угол зрения.
Спектральные характеристики фильтра используются при расчете яр-кости элемента растра по величине поглощения энергии трассируемого лу-ча на пути его прохождения от источника до элемента растра.

Рис. 3. Схема оптической системы зрителя
Поле Focus характеризует расстояние между центром проекции и точ-кой картинной поверхности, лежащей на главной оптической оси.
Поле Spctr в настоящее время используется как заглушка, но должно характеризоваться структурой, описывающей спектральный диапазон, в котором данный наблюдатель "видит" сцену через некоторый светофильтр.
Поле Rastr объявляется как объект класса, в котором описывается массив векторов сканирования растра (форма картинной поверхности) [4]. Приведем фрагмент структуры этого класса.
class RASTR {
...
public:
FILE* RstrFile; // Файл с параметрами растра
DEKART* VV; // Массив векторов растра
int Nvv; // Объем растра
int Nx, Ny; // Размерности растра на картинной
// плоскости
float SX, SY, // Размеры картинной плоскости
CX, CY; // Проекция центра проекции на
// картинную плоскость
...
RASTR (FILE*);
...
};
Метод Install (ACTOR*) класса VISOR служит для реализации функ-ции ассоциирования зрителя с заданным актером при описании сцены. В этом случае система координат зрителя не является независимой, а погру-жается в систему координат актера. Все перемещения и повороты ассоции-рованного зрителя интерпретируются также в системе координат актера.
Инициализация массива элементов растра производится конструкто-ром, который формирует пространственную траекторию вектора VV скани-рования картинной поверхности. Параметры картинной поверхности опи-сываются в файле RstrFile, а процедура формирования растра основывает-ся на методах, описанных в [4].
Синтез изображений сцены во всех ракурсах, соответствующих всем заданным наблюдателям, организован как обслуживание каждого наблю-дателя некоторым объектом Drcp класса DRCP, представляющим собой драйвер развертки центральной проекции.
Перед началом развертки объект Drcp принимает от каждого наблю-дателя атрибуты, характеризующие ракурс, в котором данный наблюдатель видит сцену (вектор положения, вектор зрения, фокусное расстояние и т.д.), а также параметры растра и спектральные характеристики, в связи с чем задан квалификатор доступа к наблюдателю со стороны класса DRCP.
Для приема параметров класс DRCP снабжен методом Hook, фраг-мент которого приводится:
void DRCP :: Hook (VISOR* V)
{
...
OO = V->OO; // Прием параметров, связывающих
GO = V->GO; // ракурс изображения с системой
NC = V->NC; // координат наблюдателя
// Прием параметров, необходимых
Focus = V->Focus; // для синтеза изображения,
Rastr = V->Rastr; // разворачиваемого на заданной
Spectr = V->Spectr; // картинной поверхности
...
}
5. ОБЪЕКТЫ КЛАССА HYPER
Для синхронного формирования изображений на полиэкранах и сте-реопар и других агрегатных изображений (получаемых одновременно для нескольких центров проекции и направлений зрения) в систему введен класс HYPER. Этот класс описывает контейнерный объект, выполняющий роль агрегатного зрителя, фактически состоящего из нескольких зрителей, – массива объектов класса VISOR. Объекты класса VISOR, как подобъекты объекта класса HYPER, приобретают пространственные атрибуты и пара-метры картинных поверхностей, согласованные с центром и осью зрения агрегатного зрителя. При этом в описании сцены фигурируют только объ-екты класса HYPER, скрытно создающие внутри себя подобъекты класса VISOR в соответствии с заданными атрибутами, которые будут жестко свя-заны в пространстве. В итоге при перемещении и вращении группа объек-тов класса VISOR будет вести себя как единый объект.
В данном случае необходимы два объектных механизма: наследование и полиморфизм. Кроме того, необходимо создать контейнерный объект, так как число подчиненных зрителей должно быть произвольным. Подчи-ненные зрители, наследуя пространственные атрибуты главного зрителя, должны создать на их основе свои собственные пространственные атрибу-ты, набор которых (и механизм их создания) зависит от типа главного зри-теля. Поэтому функцию создания выполняет объект абстрактного класса – виртуальный сборщик ракурсов подчиненных зрителей, который в зависи-мости от типа агрегатного зрителя разворачивает в пространстве и на-страивает соответствующим образом конкретную систему наблюдения.
Например, для синтеза стереопар необходимо создать двоих наблю-дателей, разнесенных на расстояние стереобазы, и ориентированных в со-ответствии с заданным углом вергенции.
При синтезе панорам используется совсем другая схема. Может пона-добиться совместить несколько центров проекции в одной точке, а оси зре-ния развернуть в соответствии с разбиением общей для всех зрителей кар-тинной поверхности, ее формой и т.д.
Контейнерный класс HYPER определен в системе следующим обра-зом.
class HYPER {

public:
AGREGAT* Master; // Виртуальный сборщик ракурсов
char name[33]; // Тип главного зрителя
int NV; // Число подчиненных зрителей
VISOR* V; // Массив подчиненных зрителей
DEKART OO, // Положение и
NC; // ориентация главного зрителя
MATRIX GR, // Матрицы вращения
RO; // главного зрителя
FILE* PtrEv; // Поток для приема атрибутов движения

HYPER ();
void Compile (FILE*); // Проход по тексту сцены
void MakeVisor (); // Генератор ракурсов
void Move (DEKART, DEKART); // Перемещение и вращение агрегата
void Install (ACTOR*); // Совмещение с системой
// координат актера
};
Функции Compile и Move здесь выполняют ту же роль, что и в классе VISOR. Функция MakeVisor формирует массив зрителей, располагает цен-тры проекции и наводит векторы зрения в соответствии с требуемым набо-ром ракурсов.
Объект Master класса AGREGAT служит для формирования набора ракурсов, на основе определения числа, расположения, ориентации и опти-ческих параметров зрителей при каждом конкретном случае. Класс AGREGAT является абстрактным (поэтому объявлен указатель объекта Master ), и описан следующим образом.
class AGREGAT {
public:
FILE* Fptr; // Поток атрибутов движений
char name[33]; // Тип главного зрителя
int NV; // Число подчиненных зрителей
DEKART* OO; // Центры проекций подчиненных зрителей
DEKART* NC; // Направления зрения подчиненных зрителей
float* FC; // Удаления картинных плоскостей
// от центров проекции
virtual void Adjust() = 0; // Чистая виртуальная функция
// настройки оптики
};
Фактически, производные от этого класса объекты создают своих кон-структора и настройщика генератора ракурсов в зависимости от типа сложного зрителя (стереотруба, полиэкран конкретного вида и т.д.), кото-рый опознается в результате обработки файла описания сцены. На базе класса AGREGAT создаются классы, конкретизирующие тип сложного (аг-регатного) зрителя по его имени, считываемому из файла описания сцены.
Приведем примеры описания двух производных классов, которые на-следуют универсальные атрибуты агрегатных зрителей, а также реализуют специальные атрибуты и функции, соответствующие конкретной разно-видности сложного зрителя.
Агрегатный зритель, синхронно формирующий стереопару схематич-но изображен на рис. 4. Описание соответствующего класса выглядит сле-дующим образом:
class STRPARA : public AGREGAT {
public:

float Base; // Стереобаза (расстояние между зрачками)
float Target; // Точка, на которую наводятся оси зрения
float FOCUS; // Фокусное расстояние нормального глаза
int StrobDelay; // Задержка при стробировании
int InitState; // Начальная фаза стробирования
STRPARA ();
void Adjust (); // В данном случае – регулировки угла
// вергенции и фокуса
};
Несмотря на то, что параметра Target в объявлении производного класса STRPARA вполне достаточно для выставления угла вергенции, до-полнительно может использоваться функция изменения этого угла void Adjust(). Эта функция может потребоваться для реализации активных ме-тодов коррекции ракурсов, связанных с некоторыми видами спонтанных движений глазных яблок (дрейф, тремор и т.п. [6]), или для стимулирова-ния вергентного движения глаз при настройке взгляда на нужную глубину сцены). Кроме того, для шлем-дисплейной системы с динамической кор-рекцией ракурсов необходима непрерывная подстройка фокуса при изме-нении точки прицеливания глаз.

Рис. 4. Пространственные атрибуты стерео-агрегата
Фрагмент конструктора для стерео-агрегата:
#include "agregat.hpp"
#include "strpara.hpp"

strpara :: strpara ()
{
<чтение из файла сцены атрибутов стерео-агрегата>
strcpy(name, "strpara");
NV = 2; // Число ракурсов задано априори (2 направления)
OO = new dekart[NV]; // Выделение места для
NC = new dekart[NV]; // атрибутов

for (int i=0; i {
<инициализация атрибутов стерео-агрегата>
}
}
Другим примером является агрегатный зритель, синхронно форми-рующий изображения на четырех наружных боковых стенках куба (“аква-риум” рис. 5.):
class AQUAR_4 : public AGREGAT {
...
AQUAR_4 ();
void Adjust (); // Регулировка фокусов и ориентации
// картинных плоскостей
};

Рис. 5. Определение пространственных атрибутов виртуальных зрителей, формирую-щих изображение “аквариума”.
Картинные поверхности должны быть расположены в расчете на на-блюдение изображений, как бы через прозрачные стенки. При движении наблюдателя вокруг “аквариума” изображения на экранах должны коррек-тироваться в соответствии с изменением положения оптического центра и ориентации картинных плоскостей относительно осей зрения. Если стенки ориентированы под прямым углом друг к другу (рис. 5), наблюдатель мо-жет видеть одновременно либо одну, либо две стенки (хотя плоскостей че-тыре).
Схема случая, когда наблюдатель окружен 4-мя стенами (“обычная комната”), на которые проецируется изображение виртуальной среды, по-казана на рис. 6. Как и в предыдущем случае, изображение на стенах должно корректироваться при движении и поворотах головы наблюдателя, но, по сравнению с рис. 5, здесь виртуальная среда и наблюдатель поменя-лись местами.
На схемах (рис. 5 и 6) хорошо видно, почему необходимо корректиро-вать ракурс проекции виртуальной сцены на экранную плоскость в зависи-мости от ее ориентации по отношению к наблюдателю. Это делается для компенсации угловых искажений проекций на экране, если его плоскость не ортогональна оси зрения наблюдателя. Соответствующая установка и поворот картинных поверхностей по отношению к центру проекции в ко-нечном итоге обеспечивают видимость проекций сцены в более правиль-ном ракурсе и создают иллюзию отсутствия стен комнаты или прозрачно-сти стенок “аквариума”.

Рис. 6. Определение пространственных атрибутов виртуальных зрителей, формирующих изображение панорамы.
На рис. 7 и 8 показаны угловые пары плоских центральных проекций виртуального тест-объекта, совмещенные по линии вертикального ребра. Хорошо видно, что настройка атрибутов объектов VISOR обеспечивает очень высокую точность сшивания фрагментов проекций. Изображения получены в расчете на наблюдение их на экранных плоскостях, повернутых на 90 градусов по отношению друг к другу, но на рис. 7 изображение про-ецируется снаружи угла (“аквариум”), а на рис. 8 - изнутри угла (панора-ма).


Рис.7. Сшитые угловые пары проекций тест-объекта для
отображения их на экранных плоскостях “аквариума”.
Рис. 8. То же, но для отображения на плоскостях панорамы.
Приведем фрагмент конструктора для “аквариума”, отметив, что логи-ка построения конструктора для любого типа агрегатного зрителя доста-точно проста и стандартна.
#include "agregat.hpp"
#include "aquar.hpp"

AQUAR_4 :: AQUAR_4 ()
{
<прием из файла сцены атрибутов аквариума>
strcpy(name, "aquar_4");
NV = 2; // Максимальное число ракурсов
OO = new dekart[NV]; // Выделение места для
NC = new dekart[NV]; // атрибутов
...
for (int i=0; i {
<инициализация атрибутов аквариума>
}
}
Фрагмент генератора ракурсов, вызывающего виртуальные конструк-торы ракурсов после опознания типа зрителя, выглядит следующим обра-зом:
#include "agregat.hpp"
#include "strpara.hpp"
#include "aquar.hpp"
#include "hyper.hpp"
...
void HYPER :: MakeVisor ()
{
< Опознание типа главного зрителя и создание
виртуального агрегата ракурсов >

if (!strstr(name, "strpara")) Master = new STRPARA ();
else if (!strstr(name, "aquar_4")) Master = new AQUAR_4 ();
else if (!strstr(name, "aquar_8")) Master = new AQUAR_8 ();
...
else <создание агрегата ракурсов по умолчанию
или обработка ошибки>
...
NV = Master->NV; //Создание подчиненных зрителей
V = new VISOR [NV];
for (int i=0; i { ... // подчиненных зрителей
V[i].OO = Master->OO[i];
V[i].NC = Master->NC[i];
}
Master->Adjust(); // Настройка оптики
}
После опознания вида участника сцены – сложного зрителя, создается и размещается в пространстве сцены объект класса HYPER, запускающий генератор ракурсов HYPER::MakeVisor(), который после опознания типа зрителя STRPARA создает виртуальный агрегат ракурсов Master = new STRPARA().
Запускается конструктор ракурсов STRPARA::STRPARA(), который фактически принимает на себя обработку файла stereo.dlv. После возврата в объект класса HYPER, когда уже известны число ракурсов и их характе-ристики, вызываются конструкторы подчиненных зрителей, которые соз-дают объекты класса VISOR.
В конечном итоге генератор ракурсов MakeVisor заполняет поля каж-дого из только что созданных подчиненных зрителей V[i], а затем настраи-вает их оптические параметры.
При необходимости виртуальный метод Adjust() можно использовать для обработки событий, связанных с изменением атрибутов подчиненных зрителей. Метод Move(DEKART, DEKART) главного зрителя вызывает аналогичные методы каждого из подчиненных зрителей, предварительно преобразовав их матрицы вращения и ряд других необходимых в данном случае атрибутов по координатам, полученным из потока событий.
Рассмотрим пример описания сцены head.dlv, содержащей объявление виртуального агрегатного зрителя, который должен формировать изобра-жения стереопар с учетом положения и ориентации головы реального на-блюдателя, а также вергентных движений его глаз (пример рассчитан на подключение шлем-дисплея).
head.dlv
{ ...
HYPER strpara V1
Zoom = 1 // Кратность фокуса
Base = 0.07 // Стереобаза
Target = 10. // Точка прицеливания

SpectralBand = WHITE

place.x = 0. rotate.x = 0.
place.y = 0. rotate.y = 0.
place.z = 0. rotate.z = 0.
...
}
В этом примере объект класса HYPER в результате опознания типа зрителя STRPARA инициализирует двух наблюдателей, разнесенных в плоскости, ортогональной оси зрения на 0.07 метра (параметр Base ) и на-целенных на точку, удаленную на 10 метров от центра стереобазы (пара-метр Target служит для задания угла конвергенции). Оба наблюдателя (это глаза) увидят сцену "невооруженным глазом" (параметр Zoom=1 ).
Примерно так же осуществляется развертывание группы 2-х подчи-ненных зрителей, которые формируют изображение сцены в "аквариуме". В результате можно наблюдать синхронное развитие событий на 4-х мони-торах, обращенных "спиной" друг к другу, при движении вокруг них ре-ального наблюдателя.
Заметим, что можно образовать группу из 8 зрителей, по атрибутам которых будет синтезировано 4 стереопары для каждой стенки "аквариу-ма"). Для этой цели можно было бы сформировать объект типа “SuperMasterVisor”, состоящий из зрителей на 2-х уровнях. Но вместо это-го легче создать дополнительный производный класс AQUAR _8 по базо-вому абстрактному классу AGREGAT с 4-мя одноуровневыми зрителями.
В приведенных выше примерах положение подчиненных зрителей за-дается статично, в соответствии с координатами, считываемыми из файла .dlv. В тех случаях, когда положение и ориентация зрителей должны ме-няться в динамике, объект Nario вызывает метод MasterEvent(FILE* EventPtr). Этот метод осуществляет прием данных о положении и ориента-ции головы наблюдателей их потока EventPtr вместо считывания их из файла .dlv. В подразделе 2 был приведен пример ссылки на потоки данных при помощи директивы link, устанавливающей связь с некоторой областью данных, в которой периодически корректируются данные извне системы "Гипервизор". Все остальные действия по инициализации атрибутов под-чиненных зрителей производятся точно так же, как и при считывании этих атрибутов из файла сцены.
6. ЗАКЛЮЧЕНИЕ.
Одно из основных требований, которым должны удовлетворять сис-тема “Гипервизор” – это возможность согласованного и синхронизирован-ного функционирования разнородных систем отображения, фиксирующих одновременное развитие событий в сложной сцене с разных точек наблю-дения. Описанный выше подход позволяет решить эту задачу достаточно просто.
Стандартные средства языка С++ дают возможность автоматически контролировать все множество сложных взаимосвязей между изображае-мыми и изображающими объектами. Это позволило охватить в системе “Гипервизор” самый широкий круг задач многоракурсного синтеза: поли-экранный, стереоскопический, панорамный и т.д. Экраны, на которые должно проецироваться синтезированное изображение (при этом они могут быть и просветными, и отражательными), можно располагать как угодно, – в соответствии с их положением задаются атрибуты объектов Master и V, включая различные спектры наблюдения сцены. При этом проекция может быть построена не только на картинной плоскости, но и на заданной кар-тинной поверхности. Это позволяет охватить системы типа "Head Mounted Systems" с расширенным полем зрения, неплоские панорамные экраны, а также и другие, не только существующие, но и перспективные устройства видеовывода, так как средства наследования в С++ позволяют легко рас-ширять систему классов, описывающих особенности новых устройств.
В статье не затронуты аспекты синтеза изображений в реальном вре-мени, которые становятся крайне важными, в частности, для видеоинтер-фейса с полным погружением. Однако использованный механизм описания взаимоотношений между объектами позволяет естественным образом лег-ко вживить в существующую систему средства обработки событий, сты-куемую с системным окружением MS-Windows, X-Windows и Unix Real Time.
Данная публикация отражает некоторые результаты работ, проводи-мых в рамках проекта "ГИПЕРВИЗОР", направленного на создание гра-фического интерфейса имитационного моделирования класса "виртуальная реальность". Работы проводятся при прямой финансовой поддержке Рос-сийского фонда фундаментальных исследований.
ЛИТЕРАТУРА
1. Страуструп Б. Язык программирования С++.-М.: Радио и связь, 1991.
2. Фоли Дж., вэн Дем А. Основы интерактивной машинной графики: в 2-х книгах. Пер. с англ. М.: Мир. 1985.
3. Афанасьев В.О. Синтез изображений центральных проекций отражаю-щих объектов методом обратной трассировки в ИК-диапазоне.-М.: Изд-во стандартов. 1994.
4. Афанасьев В.О. Обратная трассировка на продолжении вектора скани-рования картинной поверхности. Настоящий сборник.
5. Афанасьев В.О., Алешин В.И., Галис Р.М., Дмитрущенков В.А., Томилин А.Н. Порождение и управление поведением виртуальных актеров в сис-теме “Гипервизор”. Настоящий сборник.
6. Глезер В.Д. Механизмы опознания зрительных образов.М.-Л.: Наука. 1966.

Новые статьи на library.by:
ФИЛОСОФИЯ:
Комментируем публикацию: СИНХРОНИЗАЦИЯ ПОГРУЖЕНИЯ В ВИРТУАЛЬНУЮ СРЕДУ СИСТЕМЫ "ГИПЕРВИЗОР"


Искать похожие?

LIBRARY.BY+ЛибмонстрЯндексGoogle
подняться наверх ↑

ПАРТНЁРЫ БИБЛИОТЕКИ рекомендуем!

подняться наверх ↑

ОБРАТНО В РУБРИКУ?

ФИЛОСОФИЯ НА LIBRARY.BY

Уважаемый читатель! Подписывайтесь на LIBRARY.BY в VKновости, VKтрансляция и Одноклассниках, чтобы быстро узнавать о событиях онлайн библиотеки.