Open Inventor как средство разработки интерактивных графических приложений

Сегодня широкое распространение в качестве графического стандарта получил 3D графический интерфейс OpenGL [1], предназначенный для рендеринга сцен в трехмерном пространстве. Его реализации доступны практически на всех графических системах под ОС Unix и семействах Windows, а разработчики графической аппаратуры постоянно работают над специализированными аппаратными ускорителями для OpenGL [2,3]. Однако в OpenGL имеются только базовые средства для 3D-рендеринга, но нет аппарата для ввода и структурного описания сцены, который необходим для разработки интерактивных графических приложений. Следующим шагом в развитии открытых графических стандартов должен быть инструментарий более высокого уровня, обеспечивающий разработчика средствами структуризации, визуализации и интерактивного взаимодействия. Такой инструментарий предложен в системе Open Inventor, который сегодня выдвигается на роль стандарта де-факто.

Стандарт OpenGL не зависит от оконной среды. Это и обусловило его широкое распространение в открытых системах. Тем не менее наиболее "родной" для OpenGL является среда X Window System, для которой имеется специальное расширение GLX, обеспечивающее, помимо всего прочего, возможность прямого рендеринга (минуя X-сервер), что позволяет создавать эффективные приложения, работающие в распределенной X-среде. Отчасти это и было использовано для развития открытых графических стандартов более высокого уровня, в результате чего появился инструментарий Open Inventor [4].

1. Что такое Open Inventor?

Open Inventor (OI) представляет собой набор строительных блоков (объектов), позволяющих создавать интерактивные приложения с минимальными усилиями. Объект OI - это экземпляр класса С++, инкапсулирующий данные и методы. Набор объектов - библиотека классов C++, которую можно расширять по мере необходимости.

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

Именно этот принцип и был положен в основу OI. Иерархическая сцена представлена в виде графа - дерева, терминальные узлы (листья) которого - объекты OI, описывающие геометрические примитивы и устанавливающие режимы рендеринга примитивов. Кроме того, в граф включаются объекты, задающие общие условия рендеринга (камера и источники света). Вообще говоря, граф сцены является не деревом в чистом виде, а ориентированным графом без циклов, поскольку любой его узел может быть подчинен более чем одному вышестоящему узлу, что позволяет компактно описывать повторяющиеся структуры.

Описанная в графе сцена отображается на экран средствами рендеринга OpenGL, применяемого к графу сцены. Как правило, нет необходимости его явного использования, поскольку он запускается автоматически при изменении сцены. Применение любого действия сводится к обходу графа в соответствии с иерархией (от корня к листьям). Для каждого действия создается состояние обхода. В каждом терминальном узле выполняется инкапсулированный в нем метод, имеющий доступ к состоянию обхода. При рендеринге состояние обхода включает состояние рендеринга OpenGL, а терминальный узел вызывает изменение определенного элемента состояния обхода или выполнение той или иной команды рендеринга OpenGL. Например, узел, задающий характеристики поверхности, заменяет соответствующий элемент состояния обхода, а узел, описывающий геометрический примитив, выполняет команды рендеринга этого примитива с учетом текущего состояния рендеринга. С этой точки зрения граф сцены можно трактовать как непроцедурное представление программы на OpenGL, а его обход при рендеринге - как выполнение этой программы.

Данные объектов OI хранятся в полях, которые представляют собой не просто переменные, а объекты C++, инкапсулирующие методы setValue и getValue для установки и извлечения значений. Таким образом обеспечивается механизм, с помощью которого OI отслеживает изменения в описании сцены. Имеется возможность связывать поля направленной связью так, чтобы значение одного поля в случае его изменения передавалось в другое. Помимо полей, входящих в состав объектов OI, существуют глобальные поля, которые не входят в граф сцены, но которые можно с ним связать. Еще один вид специальных объектов, не входящих в граф сцены, - это инструменты (engines), определенным образом преобразующие значения соединенных полей. Сама по себе возможность связывания полей не очень интересна, но с помощью инструментов она позволяет реализовать наиболее простые реакции на изменения.

Граф сцены вместе с глобальными полями и инструментами, соединенными с ним, составляет базу данных сцены.

Порядок наполнения базы данных может быть произвольным. Ее можно наполнять "вручную" - конструируя объекты и включая их в иерархию. Любой фрагмент сцены, описанный в формате передачи данных OI (текстовом или бинарном), может быть извлечен из файла или подготовлен в памяти как строка (что иногда проще, чем программный способ) и включен в состав базы данных. Базу в любой момент можно редактировать: добавлять и исключать объекты, связывать их друг с другом или модифицировать. Механизм отслеживания изменений в базе данных используется для немедленной перерисовки сцены в случае наличия изменений. В результате визуальный образ сцены всегда соответствует состоянию базы данных редактируя , которую определенным образом можно получить эффект анимации.

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

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

Подобно OpenGL, OI независим от конкретной оконной системы, для связи с которой применяется библиотека компонентов, разработанная для среды X Window. В число компонентов входят область рендеринга (объект, связывающий базу данных с окном), утилиты для работы с окнами и запуска основного цикла обработки событий, транслятор событий в формат OI, интерактивные редакторы и визуализаторы сцены, встраиваемые в приложение. Имеются также средства для разработки библиотеки компонентов в любой другой оконной системе.

2. Граф сцены

Сцена имеет иерархическую структуру, описываемую в виде графа. Объекты OI, составляющие граф сцены, называются узлами. Узел, не имеющий родителей, называется корнем. Основные категории узлов: узлы группирования (Group nodes), камера и источники света, узлы преобразований, формы, свойства и, наконец, комплекты узлов (Node kits) - подграфы, составленные по заранее подготовленным шаблонам.

2.1. Иерархия сцены и обход графа

Узлы группирования (класс SoGroup) используются для группирования дочерних узлов, тем самым создавая иерархию объектов в сцене. Дочерний узел приписывается к родителю (узлу класса SoGroup) в определенном порядке (методы аddChild или insertChild). Порядок очень важен, потому что именно от него зависит обход дочерних узлов при выполнении действия.

Можно изолировать влияние узлов, составляющих группу, на состояние обхода для остальных узлов. Для этого применяется разделитель - узел класса SoSeparator (подкласс SoGroup). При входе в группу, принадлежащую разделителю, текущее состояние обхода запоминается, а на выходе - восстанавливается. Таким образом, обход узлов, составляющих эту группу, не влияет на обход остального графа.

На уровне узлов-разделителей происходит управление кэшированием и куллингом, значительно ускоряющими рендеринг. Кэширование рендеринга сохраняет дисплейный список (произвольная последовательность команд OpenGL), полученный в результате обхода подграфа под данным узлом. Если подграф не изменился, OI использует содержимое кэша для повторного рендеринга без обхода. Если куллинг включен, то для данного подграфа вычисляется ограничивающий параллелепипед, сравниваемый с видимым объемом. Если он лежит полностью за пределами видимого объема, то подграф не обходится.

Имеются средства описания альтернативных подграфов. Для этого используется переключатель - узел класса SoSwitch (подкласс SoGroup), имеющий поле whichChild, где содержится порядковый номер потомков, подлежащих обходу. Остальные потомки игнорируются. Изменяя содержимое этого поля, можно переключать направление обхода от одного подграфа к другому. Этот прием можно использовать, например, для простой анимации.

При быстром рендеринге сложных сцен очень важно уметь изображать различные части сцены с различной степенью детализации в зависимости от удаленности их от наблюдателя. Узел класса SoLevelOfDetails (подкласс SoGroup) позволяет выполнять такое описание. Как и в случае переключателя, обходится только один из потомков этого узла. Критерием выбора служит размер проекции объектов, представленных в подграфе. В поле screenArea узла-потомка хранится диапазон значений, сравниваемый с площадью ограничивающего прямоугольника. Если площадь попадает в диапазон, то она изображается при рендеринге, а остальные узлы игнорируются.

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

Разделяемые узлы представляют, таким образом, одновременно несколько различных объектов сцены. В связи с этим возникает проблема однозначной идентификации объектов, поскольку простого указания на узел недостаточно. Объект в графе сцены однозначно идентифицируется его путем (path) - цепочкой указателей на узлы, расположенные на всем пути от корня к данному узлу.

2.2. Системы координат, геометрические преобразования, источники света

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

Узел "камера" (класс SoCamera) определяет видимый объем и преобразование проецирования из 3D мирового пространства на 2D картинную плоскость. Имеется два вида проецирования: перспективное и параллельное. В этом узле задаются местоположение "камеры" и ее ориентация, параметры видимого объема, фокусное расстояние. Обычно единственный узел камеры располагается рядом с вершиной графа, так чтобы при обходе он был первым из содержательных узлов.

Чтобы увидеть сцену, описываемую графом, необходимо разместить в графе хотя бы один источник света - узел класса SoLight. Освещение - один из элементов состояния обхода. Поэтому источник освещает все узлы в графе, которые обходятся после него (с учетом узлов-разделителей). Освещенность от нескольких источников аккумулируется. Класс SoLight имеет поля, определяющие включение источника света, яркости и цвет.

2.3. Формы

Узлы форм описывают геометрию примитивов, в основном соответствующих примитивам OpenGL (включая библиотеку утилит GLU) в объектной системе координат. При рендеринге обход такого узла вызывает рендеринг примитива, выполняемый средствами OpenGL с учетом текущего состояния. Формы делятся на простые, комплексные, тексты и NURBS.

Простая форма описывает элементарное твердое тело, заданное своими размерами и расположенное фиксированным образом в объектной системе координат. К телу применяется текущее геометрическое преобразование. Имеется четыре класса простых форм: SoCube (прямоугольный параллелепипед), SoCone (конус), SoSphere (сфера), SoCylinder (цилиндр).

Комплексные формы, в основном соответствующие примитивам OpenGL и описываемые набором вершин, непосредственно в узле хранят только описание своей структуры. Координаты вершин при обходе графа извлекаются из текущего набора координат (одного из элементов состояния обхода) и подвергаются текущему геометрическому преобразованию. Набор координат выбирается в узле координат (класс SoCoordinate3) и становится текущим при обходе этого узла. Трактовка набора координат определяется типом формы. Имеются следующие классы комплексных форм: набор поверхностей, представленных независимыми многоугольниками; набор групп смежных треугольников; сетка, составленная из смежных четырехугольников; набор независимых отрезков; набор точек.

Узлы SoText2 и SoText3 описывают 2D- и 3D-изображения одной или нескольких строк текста. Текст рисуется с использованием текущего цвета и текущего шрифта, устанавливаемого узлом SoFont. Текст позиционируется в точке начала координат, подвергнутой текущему геометрическому преобразованию. Текст может быть выровнен слева или справа или центрирован относительно точки позиционирования. Плоский текст изображается в плоскости, параллельной картинной, с размерами, не зависящими от расстояния до камеры. Символы 3D текста - замкнутые твердые тела, имеющие переднюю, боковую и заднюю поверхности, - подвергаются рендерингу как обычные твердые тела с учетом текущего состояния рендеринга. Плоскость передней поверхности может располагаться произвольно. Профиль боковой поверхности может быть сколь угодно сложным и устанавливается в узлах SoLinearProfile и SoNurbsProfile.

Узлы SoNurbsCurve и SoNurbsSurface описывают NURBS кривые и поверхности. Текущий набор координат трактуется как вектор или прямоугольная матрица управляющих точек. Веса управляющих точек (для рациональных кривых и поверхностей) устанавливаются в узле SoCoordinate4. Чтобы ограничить изображаемую поверхность, необходимо описать замкнутую линию в параметрическом пространстве (узлами SoLinearProfile или SoNurbsProfile).

2.4. Свойства

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

Узел SoNormal устанавливает набор нормалей, используемых для определения ориентации поверхностей и учитываемых при рендеринге с моделью освещения PHONG. Узел SoMaterial определяет набор характеристик поверхности, включающих цвет, отражающие способности, гладкость и прозрачность. Узел SoDrawStyle выбирает стиль рисования (невидимый, точечный, линейный, заливкой областей). Узел LightModel устанавливает одну из двух моделей освещения: BASE_COLOR игнорирует источники света, принимая во внимание только цвет/прозрачность поверхности; модель PHONG учитывает все источники света. Модель затенения в OI устанавливается неявно с учетом модели освещения и характеристик поверхности. Узел SoEnvironment позволяет моделировать различные атмосферные явления - туман, дымку, смог. Узел SoShapeHints определяет, описывает ли объект границу твердого тела, является ли поверхность выпуклой, задает порядок обхода вершин, отмечая наружную сторону, разрешает автоматическую генерацию нормалей. Узел SoTexture2 задает 2D карту текстуры и устанавливает модель накладывания текстуры на поверхность. Модель определяет, каким образом значения текстуры взаимодействуют с цветом и прозрачностью поверхности. Текущая карта текстуры до наложения на поверхность подвергается 2D геометрическому преобразованию, устанавливаемому узлом SoTexture2Transform.

2.5. Комплекты узлов (Node Kits)

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

В OI имеется несколько готовых к употреблению комплектов узлов. Например, комплект узлов SoShapeKit применяется для правильного встраивания в граф любой формы. Шаблон содержит узел SoCube, который при желании можно заменить на любую форму, и правильно расположенные узлы координат, материалов, геометрических преобразований и другие узлы свойств.

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

3. Сенсоры

Сенсоры - специальный класс (SoSensor) объектов, привязываемых к базе данных. Они реагируют на изменения в базе данных (сенсоры данных) или на определенные события таймера (сенсоры таймера) путем вызова callback-функций.

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

В отличие от сенсоров данных, привязанных к графу сцены, сенсоры таймера явно включаются в таймерную очередь, где они упорядочиваются не по приоритету, а по времени их запуска. Перед включением в очередь устанавливаются временные параметры - когда и сколько раз вызвать callback-функцию.

4. Инструменты (engines) и соединения полей

Инструменты - классы объектов, которые можно соединять с полями узлов графа сцены или глобальными полями и использовать для анимации частей сцены или для взаимного ограничения элементов сцены. Это средство позволяет инкапсулировать и геометрию, и движение в единственном графе. В отличие от сенсоров инструменты используют не callback-функции, а встроенные функции, поэтому их можно сохранить в файле и прочитать из файла.

Инструмент имеет входные и выходные поля, которые можно соединить с любыми полями (в частности, с входами и выходами других инструментов). Инструмент запускается, когда изменяются значения полей, соединенных с его входами, выполняет над входными значениями некоторые операции и выдает несколько результатов, попадающих в поля, соединенные с его выходами. Таким образом, может возникнуть волна изменений.

Поля можно соединять друг с другом и минуя инструменты - результат будет тот же. При изменении значения некоторого поля поле, соединенное с ним, получит такое же значение. Отметим, что один выход может соединяться с несколькими входами, но каждый вход может быть соединен только с одним выходом.

Существует несколько типов инструментов

• Анимационные инструменты, вход которых соединен с выходом поля realTime, имеющие на выходе дискретный поток значений. Предопределенное глобальное поле realTime содержит текущее время и служит источником изменений для анимации, зависящей от времени.
• Шлюзы, позволяющие управлять потоком значений посредством полей enable и trigger. Первое открывает или закрывает непрерывный поток значений, проходящий через шлюз, а второе при закрытом enable позволяет пропустить одно значение.
• Арифметические инструменты, производящие булевы и арифметические операции.

В OI имеются несколько классов узлов со встроенными инструментами, позволяющими создавать простую циклическую анимацию: SoRotor - эффект вращения объекта; SoPendulum - создание эффекта маятника; SoShuttle - узел преобразования, у которого значение сдвига колеблется между двумя крайними значениями, что создает эффект челнока; SoBlinker - переключатель, который в цикле по очереди включает обход одного из своих потомков, создавая эффект мерцания.

5. Действия

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

Нет необходимости применять действие рендеринга явно, поскольку оно вызывается автоматически при изменении сцены. Но оно имеет несколько методов, устанавливающих глобальные характеристики рендеринга OpenGL: уровень качества прозрачности, определяющий использование компонента прозрачности; метод устранения лестничного эффекта (antialiasing).

Действие "указка" находит примитивы, лежащие на луче, исходящем от наблюдателя и проходящем через заданную точку на ближней плоскости видимого объема (обычно определяется пикселем в окне) и возвращает список узлов-форм, соответствующих найденным примитивам, упорядоченный по их удаленности. Оно применяется в основном при обработке событий.

Действие обратного вызова позволяет обойти граф сцены и аккумулировать состояние обхода. При обходе узлов определенного типа вызываются callback функции, имеющие доступ к состоянию обхода. Это действие обеспечивает удобный механизм для создания собственных прикладных действий без расширения классов OI, например для расчета массы тел, представленных примитивами сцены.

6. Обработка событий и интерактивное взаимодействие

Модель обработки событий в OI не основана ни на какой конкретной оконной системе. Происшедшее в оконной среде событие транслируется в формат OI - создается объект класса SoEvent, содержащий все необходимые данные о событии. Затем к корневому узлу графа сцены применяется действие обработки событий. Граф обходится точно также, как и для других действий. В каждом узле выполняется метод isHandled, дающий положительный ответ, если узел берется за обработку именно этого события. Узел - обработчик события должен иметь метод setHandled, который, собственно, и реализует взаимодействие. Чтобы начать интерактивное взаимодействие, необходимо в граф сцены включить соответствующий узел - обработчик событий так, чтобы он обходился первым среди узлов, реагирующих на данное событие. Узел может потребовать, чтобы все последующие события направлялись непосредственно ему до особого указания. Такой запрос называется захватом (grabbing). Например, манипулятор после нажатия кнопки мыши захватывает все последующие события, пока кнопка не будет отпущена. Когда взаимодействие заканчивается, узел следует удалить из графа.

В OI имеется несколько типов узлов - обработчиков событий, реализующих готовые средства взаимодействия: SoSelection (реализующий выбор), буксировщики и манипуляторы. Узел SoEventCallback (вызывающий callback-функции в методах isHandled и setHandled) реализует специфическое прикладное интерактивное взаимодействие.

6.1. Выбор

Узел класса SoSelection, обычно подвешиваемый к верхушке графа, реагирует на нажатие левой кнопки мыши и реализует выбор графических примитивов. Выбранные примитивы выделяются (highlighted) либо их изображением в каркасном виде линиями определенного цвета и типа, либо изображением ограничивающего параллелепипеда вокруг них. SoSelection включает методы для управления списком выбора, выделения выбранных примитивов, использования callback функций, вызываемых при изменении списка выбора.

6.2. Буксировщики и манипуляторы

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

Поля буксировщика можно соединять с другими полями или инструментами и таким образом устанавливать зависимость графа сцены от буксировки. Можно написать callback-функции, вызываемые при нажатии, отпускании или перемещении мыши или при изменении полей буксировщика. И наконец, можно использовать простые буксировщики, как строительные блоки для создания более сложных буксировщиков.

В OI имеется большой набор буксировщиков, осуществляющих управление разнообразными поворотами, переносами, масштабированиями в 2D- и 3D-измерениях с предоставлением различных пользовательских интерфейсов, включая трекбол или управляющий параллелепипед (Handle Box). Поскольку буксировщик - это комплект узлов, можно изменить внешний вид буксировщика, изменив геометрию его примитивов, создаваемых по умолчанию. С каждым буксировщиком связан файл ресурсов, в котором в формате OI описана конфигурация по умолчанию.

В отличие от буксировщика, являющегося комплектом узлов, манипулятор представляет собой интерактивно редактируемую версию (подкласс) некоторого узла (преобразования или источника света), которая использует буксировщик, чтобы реагировать на инициируемые пользователем события и редактировать собственные поля. При создании манипулятора задаются геометрические параметры его буксировщика в локальной системе координат. Обычно их задают так, чтобы группа примитивов, подвергающаяся манипулированию, помещалась внутри буксировщика.

Манипулятор обеспечивает легкий способ включения в приложение непосредственного взаимодействия в 3D-пространстве. Так манипулятор, заменяющий источник света, позволяет пользователю интерактивно перемещать источник, освещая сцену с разных сторон. Манипулятор, заменяющий узел преобразования, применяемого к некоторой группе геометрических примитивов, позволяет пользователю интерактивно менять параметры преобразования и тем самым поворачивать, перемещать или масштабировать сам буксировщик и эту группу. Например, манипулятор SoTrackBallManip вставляет в сцену трекбол (сферу, ограниченную тремя взаимно перпендикулярными лентами), позволяя изменять поля узла SoTransform, масштабируя и поворачивая объект внутри трекбола. Манипулятор SoHandleBoxManip вставляет управляющий параллелепипед, окружающий объект и имеющий управляющие метки на углах и сторонах. Указывая на метки и буксируя их, пользователь меняет масштаб и положение параллелепипеда и соответственно объекта внутри него.

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

7. Интерактивные редакторы и визуализаторы

В состав библиотеки компонентов для X Window входят многократно используемые модули со встроенным интерфейсом для интерактивного редактирования сцены. Каждый компонент представляет собой виджет в стиле Motif и может использоваться сам по себе или в комбинации с другими. Компонент может иметь свое собственное окно или размещаться в одном из имеющихся. Он обладает методами для управления своим поведением. Имеется два способа передачи данных из компонента в приложение: привязать компонент к узлу в графе сцены или задать callback-функции, чтобы извещать приложение об изменениях в компоненте. Два основных класса компонентов - редакторы и визуализаторы (viewers).

Интерфейс редактора позволяет интерактивно модифицировать поля того узла, к которому он привязан, например узла материалов или источника света, с немедленным отражением изменений в окне рендеринга.

Визуализатор всегда привязывается к корневому узлу и позволяет интерактивно менять параметры камеры, создавая эффект ее движения. Если в графе отсутствует узел камеры, то визуализатор его создает и размещает у корня графа. По умолчанию визуализатор добавляет направленный источник света, непрерывно следующий за камерой. Все визуализаторы имеют область рендеринга, в которой отображается сцена; колесики и ползунки по краям окна, управляющие горизонтальным и вертикальным перемещением камеры и наездом; Pop-up меню, управляющее поведением компонента, например позволяющее изменить стиль рисования всей сцены (каркасный, с удалением скрытых линий, без текстур и т. д.); иконки с правой стороны, сокращающие некоторые pop-up операции; дополнительные иконки приложения в левом верхнем углу.

8. Средства расширения

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

Заключение

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

Сегодня реализации OI доступны на большинстве Unix-платформ и Win32 (Windows NT, Windows 95). На базе OI разработано множество приложений в самых различных областях. В частности, технология OI лежит в основе известной системы визуализации научных данных Open Explorer [5]. Стоит отметить, что OI использован в качестве основы для VRML - 3D.

Литература