CC BY
52
Модуль поддерживает возможности визуализации, помогающие существенно повысить реализм синтезируемых трехмерных сцен: поддержка сложных материалов с картами основной текстуры, прозрачности, с картами отражений и шероховатостей объекта; поддержка плоских зеркал, моделирование теней от источников света, моделирование затухания источников света и эффекта прожектора и многое другое. Модуль имеет уникальные возможности реализации дополнительных эффектов, возникающих в оптических системах наблюдения либо в системах передачи сигнала в реальной обстановке и требующих сложного моделирования на компьютере: блики от ярких источников света, эффект черно-белого режима, эффект засветки и пересветки объектива, синтез белого шума с варьируемой интенсивностью, а также моделирование расфокусировки объектива.
Управление камерами для навигации по трехмерной сцене и управление объектами производится с помощью стандартных манипуляторов, при этом параметры управления являются конфигурируемыми, что позволяет настроить наиболее удобное управление для любой ситуации.
Кроме навигации по трехмерной сцене модуль также обеспечивает изучение сцены и интерактивное взаимодействие с ней. При наведении указателя мыши производится вывод сопоставленной ему текстовой подсказки (если таковая задана). При клике левой кнопкой мыши на некотором объекте, если ему сопоставлено некоторое действие, производится запуск соответствующего файла сценария, который может содержать, например, команды на запуск некоторых анимационных треков, изменения цвета индикаторов и многое другое.
Важной особенностью модуля является реализация возможности конфигурирования параметров визуализации и практически всех параметров сцены с помощью команд на встроенном скриптовом языке. Это позволяет адаптировать параметры отображения сцены под необходимые условия и реализовать желаемый сценарий визуализации сцены. Команды на простом скриптовом языке задаются в конфигурационных файлах и подгружаются в необходимый момент. Это актуально именно для системы просмотра мультимедийных инструкций, поскольку позволяет в большинстве случаев обойтись одной сценой для всей инструкции и избавиться от перезагрузки сцены на каждом из пунктов. Общая сцена в таком случае содержит анимационные треки объектов для реали-
зации необходимых пунктов инструкции и включает нужные средства наблюдения и объекты. На этапе визуализации некоторого пункта производится загрузка соответствующего конфигурационного файла. Создание конфигурационных файлов для отдельных пунктов инструкции является гораздо менее трудоемким этапом, нежели трехмерное моделирование сцены, и осуществляется либо самим дизайнером трехмерной сцены, либо отдельным человеком на заключительном этапе адаптации сцены для мультимедийной инструкции.
Перечень скриптовых команд управления сценой можно разделить на несколько типов: системные команды; команды работы с материалами; команды управления узлами сцены; команды работы с анимационными треками; команды конфигурирования управления; команды работы со звуком; команды работы с выводом изображения.
Модуль поддерживает также технологию отображения сцены в стереорежиме, что повышшает степень восприятия материала. Стереорежим позволяет рассматривать трехмерные образы объектов в наиболее естественном виде с учетом бинокулярной особенности зрения человека. Ощущение объема виртуальной сцены позволяет более точно понять габариты объектов и их пространственное расположение, что обеспечивает лучшее усвоение представленного материала. Поддержка стереорежима реализована с использованием поляризационного метода и метода очков затворного типа.
Предлагаемая система может быть применена для создания мультимедийных описаний (например, опытов, экспериментов, анимаций технологических процессов), инструкций и руководств (по сборке, разборке, ремонту, эксплуатации приборов и изделий), иерархических каталогов и справочников, а также обучающих систем (особенно для изучения состава и структуры сложных трехмерных систем). С ее помощью можно автоматизировать процесс создания электронной документации по сопровождению сложного технического оборудования, а также разработки интерактивной технической документации. Наличие в этой системе двух- и трехмерной виртуальных сцен вместе с анимацией и возможностью перемещения и интерактивного взаимодействия с виртуальными объектами позволяет существенно повысить уровень понимания и скорость запоминания информации и облегчает пользование мультимедийными руководствами.
СИНТЕЗ ФОТОРЕАЛИСТИЧНЫХ ТРЕХМЕРНЫХ ИЗОБРАЖЕНИЙ В СОВРЕМЕННЫХ СИСТЕМАХ ПРЕЗЕНТАЦИЙ
С.В. Андреев, В.А. Галактионов, к.ф.-м.н., Е.Ю. Денисов, Н.Е. Кирилов (Москва)
В современном мире огромную роль играют системы презентаций, используемые для доведения информации зрителю в графическом виде. Особое место занимают компьютерные системы генерации
трехмерного представления иллюстрируемых объектов, работающие в режиме реального времени.
Одним из примеров презентационной системы является комплекс Terminal V, находящийся в Авст-
рии (см.: http://www.terminalv.at). Различные компании арендуют комплекс для проведения своих презентаций, конференций, демонстраций собственных разработок. Комплекс представляет собой демонстрационный зал со зрительными местами, обращенными к трем соединенным экранам, стоящим под углом в 120 градусов - фронтальному, левому и правому (см. рис.).
Техническая схема трех экранов Terminal V (вид сверху)
Комплекс управляется системой из семи компьютеров, объединенных в локальную сеть. Два из них управляют выводом стереокадра на фронтальный экран: первый компьютер выводит правый канал стереокадра фронтального экрана, второй - левый канал. Два следующих компьютера выводят стереокадр на левый экран и еще два - на правый. Все шесть серверных компьютеров, выводящие изображения на экраны комплекса, управляются основным мастер-компьютером, подключенным к обычному монитору (место оператора презентационного комплекса).
Таким образом, система предназначена для показа протяженных панорамных стереокадров, где каждый результирующий стереокадр состоит из трех частей (левый, правый и фронтальный экраны) и управляется оператором с помощью компьютера с обычным монитором.
По заказу одной из австрийских компаний разрабатывалось программное обеспечение, предназначенное для проведения демонстраций продукции в режиме реального времени в демонстрационном зале Terminal V. При разработке программного обеспечения возникли специфические проблемы: разделение стереокадра на три составляющие и синхронизация вывода изображения. Решение первой проблемы очевидно, рассмотрим специфику второй.
Известно, что при генерации кадра системами, работающими в режиме реального времени, используется система с двойной буферизацией, когда расчет и отображение каждого последующего кадра происходит в так называемом «заднем буфере», не видимом на экране. Таким образом, зритель не наблюдает промежуточных состояний неоконченного расчета и отображения кадра. И только когда кадр полностью рассчитан, происходит практически
мгновенный обмен буферов и содержимое заднего буфера выдается на экран, тем временем система начинает расчет следующего кадра и так далее.
В случае расчета частей одного и того же кадра несколькими компьютерами возникает проблема синхронизации процесса обмена буферов. Время расчета части кадра напрямую зависит от сложности участка сцены, попавшего в эту часть. Естественно, какому-то из компьютеров достанется более сложный для расчетов участок, и он потратит на расчет своего участка большее время, чем другие. В общем случае все компьютеры закончат расчет своих участков кадра в разное время. И если не производить контроль обмена буферов для всей системы, получится хаотически рассогласованная картина смены кадров правого, фронтального и левого экранов, причем несогласованность возрастет, учитывая наличие стереоканалов (правый/левый на каждый экран).
Существуют два пути решения проблемы генерации результирующего стереокадра в комплексе Terminal V - аппаратный и программный.
Аппаратное решение. Компанией nVidia разработано семейство видеокарт Quadro G-Sync (см.: http://www.nvidia.ru/page/quadrofx_gsync.html).
NVIDIA Quadro G-Sync является дополнительной видеокартой, которая предоставляет функциональность Framelock/Genlock, синхронизацию вывода изображения из буфера кадров с частотой обновления, обеспечивая высокие уровни реалистичности, визуализации и совместных возможностей.
Однако есть довольно существенный недостаток такого решения - высокая стоимость продуктов линии G-Sync. Например, стоимость только одной видеокарты G-Sync достигает в среднем 4-5 тысяч долларов, а их в данной системе необходимо семь.
Проблему многократного сокращения стоимости можно решить программным путем. Принцип решения прост: мастер-компьютер информирует каждый из серверных компьютеров, какую часть кадра предстоит рассчитать каждому из них.
Каждый из серверных компьютеров вычисляет свою часть результирующего стереокадра и посылает сообщение на мастер-компьютер, не производя более никаких действий, а только ожидая ответной команды.
Как только мастер-компьютер получит сигнал, что все части кадра рассчитаны, он выдает команду всем серверам об обмене буферов, результирующий стереокадр появляется без рассогласования сразу на трех экранах.
Весь обмен информацией (данные, синхронизация) происходит через локальную сеть по стандартным протоколам обмена.
Такой подход удешевляет систему, позволяя отказаться от дорогостоящего дополнительного оборудования класса high-end, и, соответственно, увеличивает области применения данного решения.
В большинстве современных систем презентаций пользователю предоставляется интерфейс достаточно высокого уровня, позволяющий работать со сложными сценами, не задумываясь о деталях взаи-
модействия с графикой нижнего уровня и системными программными интерфейсами. Разработчик отгорожен от деталей взаимодействия с низкоуровневой графикой и системными программными интерфейсами и может сконцентрироваться на разработке собственно приложения.
В нашем случае в качестве такой основы был взят разработанный в отделе машинной графики института прикладной математики им. М.В. Келдыша РАН программный комплекс FLY (см.: A. Ignatenko, B. Barladian, K. Dmitriev, S. Ershov, V. Galaktionov, I. Valiev, A. Voloboy. A Real-Time 3D Rendering System with BRDF Materials and Natural Lighting. Proc. Graphi-Con-2004. Moscow. 2004), позволяющий отображать сцены со сложной геометрией, оптически сложными материалами и разнообразными источниками освещения, включая дневной свет. Комплекс FLY поддерживает специфические для OpenGL атрибуты материалов сцены, необходимые для интерактивного показа в режиме реального времени (используя аппаратное ускорение), кроме того, он оснащен модулем трассировки лучей для генерации фотореалистичных изображений.
Имеющийся в этом комплексе модуль распределенных вычислений был расширен подсистемой визуализации и подсистемой синхронизации отображения.
Общая идея визуализации состоит в следующем: одна и та же сцена (набор объектов со своими характеристиками поверхностей, набор источников освещения и т.д.) обрабатывается и визуализируется каждым из серверных компьютеров независимо. Разница между ними состоит в том, что каждый сервер-компьютер использует для визуализации свое положение камеры (передаваемое мастер-компьютером), соответствующее положению рассчитываемого участка на общем большом экране. Стереоизображение является частным случаем многоэкранной визуализации и реализуется так же: два сервер-компьютера рассчитывают два изображения, соответствующие левому и правому глазам. Для этого мастер-компьютер передает серверам положение камер, слегка смещенных друг относительно друга, раздвинутых на расстояние стереобазы. В процессе показа система презентации автоматически синхронизирует показы левого и правого кадров со специальным устройством в очках, обеспечивающим попеременное закрывание левого и правого глаза. Таким образом, левый глаз всегда видит только левые кадры, а правый правые.
Особенности решения проблемы таковы:
— поскольку в общем случае серверы могут быть оснащены различными видеокартами, необходим механизм адаптации мастер-компьютера к возможным различиям видеосистем серверных компьютеров (разрешение, частота, глубина цвета и т.д.) для обеспечения работоспособности системы в целом;
— мастер-компьютер должен обеспечить отображение полного набора элементов управления, позволяющих оператору производить манипуляции как с объектами сцены, так и с камерой, что необходимо для интерактивности процесса презентации; серверы,
напротив, должны показывать только результирующее изображение без элементов управления, которые в этом случае являются лишними;
— необходимо обеспечить самовосстановление системы визуализации после сбоев сети и/или серверов без полного ее перезапуска.
После загрузки сцены мастер-компьютер передает каждому серверу эту сцену со всеми атрибутами (текстура, свойства поверхностей, источники освещения и т.д.), так что каждый сервер имеет полную копию сцены и способен ее обсчитывать независимо от других. Передача сцены новому серверу происходит после изменения списка серверов (в случае добавления сервера).
Затем для визуализации каждого кадра выполняются три основных этапа.
1. Мастер-компьютер передает каждому серверу новые параметры камеры - ее координаты, координаты точки назначения, угол поля зрения. Эти параметры могут быть либо рассчитаны мастер-компьютером как результат воздействия оператора на координатное устройство ввода, или вычислены автоматически как результат движения камеры по заранее заданной траектории.
2. Каждый сервер рассчитывает следующий кадр, соответствующий индивидуальным параметрам камеры, в заднем буфере и по окончании расчета информирует мастера о готовности кадра.
3. По получении сигнала готовности от всех серверов мастер выдает им всем синхронную команду на отображение готового кадра.
При тестировании выяснилось, что при использовании стандартного для Windows протокола обмена RPC, используемого в 100-мегабитной сети TCP/IP, слишком велики задержки в передаче команд и данных, обусловленные стандартом и особенностями протокола TCP/IP. Так, максимальная скорость для двух серверов (то есть при использовании только стереорежима) составила 10 кадров в секунду, что недопустимо мало для обеспечения гладкого воспроизведения. Кроме того, эта скорость падает еще больше с увеличением числа серверов. Проблему можно было бы решить, перейдя на более скоростную версию протокола TCP/IP (1 гигабайт в секунду), однако был выбран другой путь - организация обмена командами для высокоскоростной синхронизации серверов на основе протокола UDP, используемого в той же 100-мегабитной сети TCP/IP. Недостатками UDP по сравнению с TCP/IP (отсутствие подтверждения приема данных, то есть возможная потеря пакетов) можно пренебречь при условии работы в локальной сети, где потери пакетов минимальны.
Задание серверов, участвующих в процессе визуализации, происходит следующим образом. На первом этапе выбираются серверы, участвующие в совместной визуализации. Программа проверяет, способен ли указанный сервер участвовать в визуализации (то есть что на нем установлен и активирован соответствующий программный модуль), и в случае положительного результата указанный сервер добавляется в список.
На втором этапе выбираются параметры стереоизображения.
Пользователь (оператор) указывает соответствие серверов каналам (то есть какой сервер будет производить расчет кадра для левого глаза, а какой для правого). Задается разрешение и частота обновления экрана для каждого сервера (предварительно мастер-компьютер запрашивает серверы обо всех возможных разрешениях и частотах, и указанные параметры выбираются пользователем из списка, что позволяет исключить проблемы, связанные с указанием заведомо не поддерживаемого разрешения). Здесь же указывается величина стереобазы, иначе говоря, расстояние между виртуальными глазами, в качестве которых выступают камеры. После завершения процесса настройки серверов все изменения в сцене, производимые на мастер-компьютере, синхронно рассчитываются и отображаются на экранах, связан-
ных с серверными компьютерами.
В заключение отметим, что основная цель данной работы была сформулирована исходя из специфики использования презентационного комплекса Terminal V: осуществить демонстрацию на комплексе трехмерных изображений, смоделированных с физически аккуратной картиной глобальной освещенности объектов, без использования дополнительных дорогостоящих аппаратных средств.
Для достижения этой цели было разработано и воплощено программное решение, позволяющее осуществить требуемую демонстрацию на оборудовании, штатно входящем в комплект презентационного комплекса.
Система была успешно опробована на оборудовании комплекса Terminal V.
Работа была частично поддержана компанией INTEGRA Inc. (Япония).
ИССЛЕДОВАНИЕ ПОВЕДЕНИЯ ПРОЦЕССОВ ОПЕРАЦИОННОЙ СИСТЕМЫ
Д.А. Лысенко, А.Г. Мадера, д.т.н., В.В. Макаров, к.т.н., В.Н. Решетников, д.ф.-м.н, В.П. Челноков, к.ф.-м.н. (Москва)
Большинство современных систем безопасности работают по одинаковому принципу распознавания нарушителей в системе: в каждой из подобных систем имеется специальная база данных (БД) с образцами сигнатур всех известных на текущий момент вирусов или БД всех возможных сетевых атак. Для выявления потенциально опасных программ (ПОП) каждая запись из этой БД сравнивается с последовательностью машинных команд программы; решение о разрешении или запрете доступа принимается после выполнения всех сравнений. Отсюда вытекают две основные проблемы: необходимость регулярного обновления сигнатур и работа постфактум.
Вместо статического анализа кода программы предлагается отслеживать динамику ее работы и создавать статистический портрет программы (СПП), выявляя некорректность выполнения программы. Достоинство такого способа - обнаружение вредоносного поведения прежде, чем оно окажет на систему какое-либо губительное воздействие, а также устранение этого воздействия (см.: В.В. Макаров, С.А. Носков. Прототип монитора безопасности для исследования новых принципов защиты систем. // Третья междунар. конф. по проблемам управления. М. 2006).
Если программа запущена, то она превращается в активный процесс операционной системы (ОС). В общем случае программа может порождать много процессов, авторы предлагают рассмотреть программу, порождающую только один процесс.
Рассмотрим ОС как оболочку процесса. Дело в том, что как только процесс обращается к какому-либо ресурсу, он выполняет системный вызов, то есть обращается к ОС. Снимем статистику обращений исследуемого процесса к ОС, получив СПП как цепочку системных вызовов.
Анализ СПП и уровня потребления ресурсов ОС позволяет обнаруживать в исследуемом процессе подозрительное поведение, указывающее, возможно, на зараженность вирусом, а затем компенсировать это подозрительное поведение так, чтобы не допустить сбоя в работе ОС.
Предлагается новый подход к идентификации процессов на основе статистического анализа совокупности выполняемых этим процессом системных вызовов. Предполагается, что последовательности выполнения системных вызовов для разных процессов статистически уникальны.
Получение СПП на основе анализа системных вызовов
Журнал выполнения системных вызовов. Поставим между процессами и ОС посредника, который будет перехватывать системные вызовы для каждого процесса по отдельности и записывать результаты их выполнения в файл (журнал).
Можно в качестве подобного посредника применить и другое приложение, которое будет производить более сложный анализ перехватываемых системных вызовов. Главное ограничение - время работы посредника (то есть посредник должен работать значительно быстрее самих системных вызовов).
Использование данных журнала. Вначале предлагается разбить все системные функции ОС на группы. Внутри каждой группы эти функции связаны по назначению. Например, функции создания и прекращения работы процессов объединяются в одну группу (fork, wait, exit).
Последующая нумерация системных функций (для их уникальной идентификации) производится следующим образом: сначала выделяют подмноже-
