ПРОГРАММНОЕ СРЕДСТВО ВИЗУАЛИЗАЦИИ ТРЕХМЕРНЫХ СЦЕН НА ОСНОВЕ ОНТОЛОГИЙ
С.А. Коршунов, О.А. Николайчук, А.И. Павлов
Институт динамики систем и теории управления имени В.М. Матросова СО РАН, Иркутск
e-mail: grey.for@gmail.com, nicoly@icc.ru, asd@icc.ru
Оглавление
2. Модель и архитектура программного средства визуализации
3. Онтологическое моделирование
4. Создание визуальных объектов
5. Формирование правил построения визуальных сцен
6. Генерация программного кода визуальной сцены
9. Оптимизация производительности
Данная работа описывает основные принципы разработки программного средства визуализации трехмерных сцен, а также реализуемый данным средством подход, в основе которого лежит использование онтологий для описания как самой визуализируемой области, так и правил ее трехмерного отображения. Данный подход позволяет непрограммирующему пользователю абстрагироваться от процесса написания программного кода трехмерной сцены и описать ее, оперируя терминами из исследуемой им области.
В работе изложена формальная модель программного средства, его архитектура и основные модули, перечислены используемые онтологии и их структура. Также последовательно описан процесс проектирования и создания визуальной сцены, включая этапы: онтологического моделирования, создания визуальных объектов, формирования правил описания сцены, генерации программного кода, визуализации, организации обмена данными между средством визуализации и источником данных.
В качестве основного средства для создания трехмерной графики выбран стандарт визуализации WebGL, который позволяет создавать визуальные сцены в веб-браузере пользователя. Примеры применения библиотеки и вопрос ее производительности также затрагиваются в статье.
Ключевые слова: визуализация, онтология, трехмерное моделирование, машинная графика, webgl.
1. Введение
Одним из самых перспективных направлений компьютерной графики является трехмерное моделирование, т.е. создание 3D-объектов различной сложности и направленности [1-3]. На данный момент трехмерная визуализация применяется практически в любой сфере человеческой деятельности. Объекты научных исследований становятся все более сложными и разнообразными и требуют адекватных программных средств визуализации для наглядного отображения своих результатов. Также активно внедряется визуализация в промышленных системах, где она позволяет быстро оценить ситуацию, не вникая в численные показания датчиков. В образовательном процессе визуализация применяется для создания трехмерных образовательных проектов, таких как простые анимированные обучающие материалы или сложные виртуальные лаборатории, которые позволят повысить интерес учащихся и скорость усвоения ими учебного материала [4-5] и т.д.
При этом во всех областях применения преобладают узконаправленные средства визуализации, характеризующиеся ограниченным набором встроенных объектов и эффектов, который, в общем случае, не обеспечивает возможность расширения инструментария для создания моделей, полностью соответствующих поставленной задаче [6]. При этом разработка собственной подсистемы визуализации может потребовать от пользователя значительных навыков в программировании.
Все это обуславливает необходимость разработки программного средства, которое предоставило бы пользователям расширяемый инструментарий для создания собственных визуальных подсистем различного применения, а автоматизация процесса написания кода снизила бы порог вхождения для непрограммирующих пользователей.
Цель данной работы – описание программного средства для создания пользовательских подсистем визуализации различного назначения с использованием стандарта визуализации WebGL [7].
2. Модель и архитектура программного средства визуализации
Формально опишем программное средство визуализации, как совокупность компонентов, в теоретико-множественном виде:
,
где 
– программное средство визуализации,
– редактор визуальных объектов,
– редактор визуальных сцен,
– транслятор правил описания сцены,
– модуль генерации кода объектов и сцены,
– модуль визуализации,
– система онтологического моделирования
предметной области 
,
– модуль онтологии визуальных объектов 
,
– модуль онтологии визуализации приложения 
,
– код визуальной сцены.
Результатом работы программного средства является сформированная визуальная сцена, которая в совокупности с браузером, необходимым для ее отображения, входными данными и библиотекой стандарта WebGL образует подсистему визуализации:
, (1)
где 
– подсистема визуализации,
– код визуальной сцены,
– входные данные, определяющие динамику ее
поведения,
– браузер для отображения визуальной сцены,
– программная библиотека для создания трехмерной
графики в браузере.
Отображать визуальную модель предлагается непосредственно в браузере пользователя, что избавит его от необходимости установки дополнительного программного обеспечения.
В соответствии с представленным описанием мы можем сформировать архитектуру программного средства (рис. 1).
Рис.1. Архитектура программного средства
Опишем основные функциональные компоненты:
· Модуль визуализации, позволяющий на основе структуры данных, полученной от транслятора, сформировать трехмерную визуальную сцену, соответствующую моделируемой области и содержащую визуальные объекты, созданные пользователем. В качестве средства для отображения трехмерной визуальной модели используется веб-браузер пользователя.
· Модуль генерации кода визуальной сцены и ее объектов. Генерация кода происходит на основе структуры данных, получаемой модулем от транслятора. Сгенерированный код является отчуждаемым и может использоваться вне программного средства при помощи любого веб-браузера.
Для реализации модулей, связанных с визуализацией (редактор визуальных объектов и модуль визуализации) авторами используется библиотека стандарта WebGL и библиотека Three.js, позволяющие создавать интерактивную трехмерную графику на языке JavaScript, отображаемую в веб-браузере. Все последние версии наиболее распространенных веб-браузеров (Internet Explorer, Mozilla Firefox, Google Chrome, Safari, Opera и др.) поддерживают WebGL.
Сами библиотеки предоставлют относительно низкоуровневый API для работы с 3D-графикой, но использование высокоуровневых интерфейсов и логических правил для описания структуры сцен избавляет пользователя от необходимости написания программного кода, что снижает требования к его программистской квалификаци.
Для хранения визуальных объектов, а также правил описания их поведения и компоновки в визуальную сцену, предлагается использовать ряд онтологий [8,9]:
· Онтологию предметной области для хранения информации о понятиях исследуемой области, их атрибутах и связях.
· Онтологию визуальных примитивов и эффектов для хранения информации о геометрических примитивах, которые лягут в основу всех объектов, а также всех доступных эффектах, которые могут быть к ним применены.
· Онтологию визуальных объектов для хранения информации о визуальном представлении базовых понятий исследуемой области (в виде трехмерных объектов).
· Онтологию визуализации приложения для хранения информации об объектах визуальных сцен, которые могут уточнять объекты, хранящиеся в онтологии визуальных объектов.
При отображении моделей онтологий на модель хранения данных мы получаем следующую логическую структуру базы данных (рис. 2). Представленная модель ранее описывалась в [10] и была дополнена описанием онтологии предметной области.
Рис. 2. Логическая структура базы данных, предназначенная для хранения онтологии
Согласно данной структуре, каждому объекту предметной области соответствует его визуальное представление в виде трехмерного объекта, наиболее полно отображающего все его основные свойства. Данные объекты представляют собой набор визуальных элементов и поддерживают ряд визуальных эффектов, которые изменяют их свойства или структуру.
Реализовать онтологии предлагается при помощи СУБД PostgreSQL. Использование СУБД обеспечивает поддержку целостности данных, а также высокое быстродействие при обработке данных.
Далее опишем последовательность действий для формирования (проектирования и создания) подсистемы визуализации (рис. 3).
Рис. 3. Этапы формирования визуальной сцены
Мы можем разбить этот процесс на следующие этапы:
- Онтологическое моделирование.
- Создание визуальных объектов.
- Формирование правил построения визуальной сцены.
- Генерация программного кода визуальной сцены.
- Визуализация сцены.
Подробно рассмотрим каждый этап на примере создания тестовой визуальной сцены, промышленной площадки, где расположены промышленное здание, угольный террикон, дорога и несколько транспортных средств (рис. 4).
Рис. 4. Пример визуальной сцены, построенной при помощи разработанного программного средства
3. Онтологическое моделирование
На первом этапе пользователю необходимо определить понятия исследуемой области путем создания онтологии предметной области. Для тестового примера объектами предметной области являются: промышленное здание, угольный террикон, дорога, транспортное средство.
Инструментальным средством для пользователя на данном этапе будет служить модуль онтологического моделирования (рис. 5).
Рис. 5. Фрагмент онтологии предметной области
Задача пользователя – сформировать в онтологии те понятия (а также их атрибуты и связи), которые далее будут участвовать в визуализации.
4. Создание визуальных объектов
Следующим этапом проектирования визуальной сцены является создание трехмерных объектов, визуализирующих объекты предмтной области. Для этих целей был разработан редактор визуальных объектов, использующий библиотеку стандарта WebGL и библиотеку dat.gui (рис. 6).
Визуальное представление большинства реальных объектов условно можно разложить на множество более мелких элементов стандартных форм (куб, цилиндр, сфера, плоскости различной формы и т.д.), поэтому редактор визуальных объектов представляет собой достаточно простой конструктор формирования объектов из геометрических примитивов.
Интерфейс редактора можно разделить на 3 части: рабочая область, панель управления объектами, панель редактирования элементов.
Рабочая область представляет собой трехмерное пространство, в котором размещаются объекты.
Панель управления объектами – элемент пользовательского интерфейса, который позволяет:
· определить объект, с которым в данный момент ведется работа; сохранить созданный объект в базу данных;
· загрузить объект из базы данных по его имени; выбрать каркасный режим отображения объекта;
· добавить к объекту новый элемент; выбрать конкретный элемент объекта для редактирования.
Панель редактирования элементов – элемент пользовательского интерфейса, предназначенный для редактирования визуальных элементов в составе объекта. Редактирование элемента производится путем изменения его параметров.
В тех случаях, когда одних примитивов недостаточно для создания объекта с необходимой детализацией, объекты могут создаваться на основе полигональной сетки. Их использование позволяет более точно настроить форму объекта, а также дополнять простые объекты через добавление мелких деталей. Сочетание двух этих подходов позволяет создавать трехмерную визуализацию с достаточной степенью детализации для большинства визуализируемых сцен.
Рис. 6. Интерфейс редактора визуальных объектов
Опциональным дополнением редактора является импорт объектов наиболее распространенных форматов (3ds, VRML, X3D) [11-12], так как эта возможность уже стала практически стандартной для систем визуализации.
Описание всех созданных при помощи редактора визуальных объектов сохраняется в онтологии визуальных объектов и онтологии визуализации приложения. В первом случае для создания онтологически структурированного банка (хранилища) визуальных объектов, во втором – для реализации подсистемы визуализации в контексте рассматриваемой задачи конкретной предметной области.
5. Формирование правил построения визуальных сцен
После создания набора визуальных объектов требуется скомпоновать их в единую сцену. Для этого с помощью редактора визуальных сцен необходимо описать их расположение и поведение на сцене в виде правил. В предлагаемом программном средстве правила задаются в виде графической схемы (рис. 7).
Рис. 7. Пример описания правил в виде графической схемы
Правила определяют то, как будут расположены все объекты на сцене и их дальнейшее поведение в зависимости от различных параметров (входных данных, полученных от пользователя, или параметров других объектов). Данные правила служат основой для последующей трансляции и генерации кода визуальной сцены.
Для описания структуры правил введем понятие визуальной сцены в расширенной нотации Бэкуса-Наура:
<визуальная_сцена> ::= <входные_данные> <визуальный_объект> {<визуальный_объект>}
Определим понятие визуального объекта как совокупности его основных параметров, набора визуальных элементов и правил поведения.
<визуальный_объект> ::= <свойства_объекта> <визуальный_элемент> {<визуальный_элемент>} <правило_поведения> {<правило_поведения>}
<свойства_объекта> ::= (<имя_объекта> <координаты_объекта> <углы_вращения_объекта>)
<координаты> ::= (<координата_по_оси_Х> <координата_по_оси_Y> <координата_по_оси_Z>)
Определим понятие визуального элемента как совокупности типа элемента и ключевых свойств:
<визуальный элемент> ::= <свойства_элемента> <тип_элемента>
<свойства_элемента> ::= (<имя_элемента> <каркасная_модель> <цвет> <прозрачность> <смещение> <угол_вращения_элемента>)
<тип_элемента> ::= <визуальный_примитив> | <полигональный_объект>
Определим понятие одного из типов элементов (полигонального объекта) как списка вершин и граней:
<полигональный_объект> ::= <вершины_объекта> <грани_объекта>
<вершины_объекта> ::= (<координаты> <координаты> <координаты>) {<вершины_объекта>}
<грани_объекта> ::= (<вектор3>){<грани_объекта>}
<вектор3> ::= (<номер_вершины> <номер_вершины> <номер_вершины>)
Определим понятие простого объекта как множества геометрических примитивов:
<визуальный_примитив> ::= <прямоугольник> | <сфера> | <цилиндр> | <круг> | <торус> | <кольцо>
<прямоугольник> ::= <ширина> <длина> <высота>
<сфера> ::= <радиус> <количество_сегментов_по_ширине> <количество_сегментов_по_длине>
<цилиндр> ::= <верхний_радиус> <нижний_радиус> <ширина>
<круг> ::= <радиус> <количество_сегментов>
<торус> ::= <радиус> <диаметр> <ширина> <радиальные_сегменты> <количество_сегментов>
<кольцо> ::= <внутренний_радиус> <внешний_радиус> <количество_сегментов>
Все объекты помещаются на визуальную сцену согласно правилам расположения:
<месторасположение> ::= если <имя_объекта> то <имя_объекта> расположение [<координаты_центра> | <начальные_координаты>] [<углы_вращения>|<конечные_координаты>]
Далее опишем правила поведения объектов на визуальной сцене:
<правило_поведения> ::= если <условие>{<условие>} то <действие>
<условие> ::= <параметр_условия> <оператор> <значение>
<параметр_условия> ::= <параметры_объекта> | <параметры_элемента> | <входные_данные>
<оператор> ::= < | > | = | <= | >=
Опишем все доступные действия над объектами:
<действие> ::= <визуальный_эффект>
<визуальный_эффект>::= <тип_визуального_эффекта> <имя_визуального_эффекта> <имя_объекта>
<тип_визуального_эффекта> ::= <изменение_параметра_объекта> | <изменение_параметра_элемента> | <замена_ объекта> | <замена_элемента> | <удаление_объекта> | <удаление_элемента> | <добавление_объекта>
<визуальный_эффект>:<изменение_параметра_объекта> ::= change_object_parameter <имя_объекта> <параметр_объекта> <шаг> <значение>
<визуальный_эффект>:<изменение_параметра_элемента> ::= change_element_parameter <имя_объекта> <имя_элемента> <параметр_элемента> <шаг> <значение>
<визуальный_эффект>:<замена_объекта> ::= change_whole_object <имя_объекта> <месторасположение>
<визуальный_эффект>:<замена_элемента> ::= change_whole_element <имя_объекта> <имя_элемента> <месторасположение>
<визуальный_эффект>:<удаление_объекта> ::= delete_object <имя_объекта>
<визуальный_эффект>:<удаление_элемента> ::= delete_element <имя_объекта> <имя_элемента>
<визуальный_эффект>:<добавление_объекта> ::= add_object <месторасположение>
Приведем внутрисистемное представление правил построения сцены для рассматриваемого примера (рис. 4):
Если «Build_10_r» то «Build_10_r» расположение (-470 0 0) (0 90 0)
Если «Road_20» то «Road_20» расположение (-420 0 250) (-420 0 -600) по параметру «length»
Если «Coil_3» то «Coil_3» расположение (-350 -10 -50) (0 270 0)
Если «Truck_1» то «Truck_1» расположение (420 -5 150) (0 180 0)
Если «Truck_2» то «Truck_2» расположение (420 -5 50) (0 180 0)
Данные правила описывают размещение на визуальной сцене нескольких объектов различной структуры: промышленного здания «Build_10_r», террикона (угольной насыпи) «Coil_3», грузового транспорта «Truck_1» и «Truck_2», а также дорожного полотна «Road_20».
При этом здание, террикон и транспорт размещаются с указанием координат центра объектов и углов вращения, а дорожное полотно – с указанием начальных и конечных координат, после чего для него автоматически расчитываются параметры наклона, а параметр длины увеличивается до нужного значения.
Далее описывается поведение (движение) транспорта в зависимости от различных параметров: для объекта «Truck_1» это некоторый входной параметр «t», а для «Truck_2» – параметр «z», который отражает положение объекта «Truck_1» по оси Z:
Если «t» > 0 то анимация: изменение_параметра_объекта() «Truck_1» «z» 1 500
Если «Truck_ 2» «x» > 10 то анимация: изменение_параметра_объекта() «Truck_1» «z» 1 550
В совокупности, данные правила описывают пример визуальной сцены, представленной на рис. 4.
Созданные пользователем правила при помощи транслятора преобразуются в заданную структуру данных и сохраняются в онтологии визуализации приложения. Данные правила используются модулем генерации кода для генерации кода визуальной сцены.
6. Генерация программного кода визуальной сцены
На этом этапе мы уже имеем структуру всей визуальной сцены, сформированную на основе созданных пользователем онтологий, содержащих все объекты и правила их расположения и поведения.
Структура сцены поступает в модуль генерации кода, где на ее основе формируется программный код на языке JavaScript со следующей структурой (рис. 8).
Рис. 8. Структура JavaScript-кода визуальной сцены
Приведем некоторые части программного кода основных функций, созданных на основе правил, описанных выше для рассматриваемого примера.
Функция placement() описывает расположение всех визуальных объектов на сцене, объекты распологаются с указанием координат центра и углов наклона, либо с указанием координат начальных и конечных точек и параметра расширения (листинг 1).
function placement()
{
var graphicalObject = new THREE.Object3D();
graphicalObject.name = 'Truck_test_1';
graphicalObject.position.set(-420, -5, 150);
...
var material = new THREE.MeshPhongMaterial({side: THREE.DoubleSide,
color: 0xcc334d, opacity: 0.5, shading: THREE.FlatShading, overdraw: 0.5, wireframe: 0} );
var polygonalGeometry = new THREE.Geometry();
polygonalGeometry.vertices.push(new THREE.Vector3(4, 0, -15));
...
polygonalGeometry.vertices.push(new THREE.Vector3(4, 0, -22));
polygonalGeometry.faces.push(new THREE.Face3(0,1,2, new THREE.Vector3(1, 0, 0)));
...
polygonalGeometry.faces.push(new THREE.Face3(6,7,8, new THREE.Vector3(1, 0, 0)));
polygonalGeometry.computeFaceNormals();
var graphicalElement = new THREE.Mesh(polygonalGeometry, material);
graphicalObject.add(graphicalElement);
graphicalObject.rotation.x += Math.PI/180*0;
graphicalObject.rotation.y += Math.PI/180*270;
graphicalObject.rotation.z += Math.PI/180*0;
scene.add(graphicalObject);
}
Листинг 1. Пример кода функции placement()
В данном случае функция содержит код создания объекта «Truck_1» и размещения его на сцене. Часть объекта состоит из полигональной сетки, описываемой как набор вершин и граней. Пример визуальной сцены (рис. 4) содержит несколько подобных объектов, но ввиду идентичности их программного кода, внутри функции описан только один.
Функция animation() описывает все визуальные эффекты, а также условия их срабатывания. Пример кода показывает самый простой вид анимации – перемещение визуального объекта по сцене. Оно реализовано как пошаговое изменение координаты объекта по оси Z в зависимости от значения входной переменной «t» (листинг 2).
function animation()
{
switch(t)
{
case 0:
{
object = scene.getObjectByName(‘Truck_1’);
while (object.position.z!=500)
object.translateZ(1);
}
}
};
Листинг 2. Пример кода функции animation()
7. Визуализация
Завершающий этап создания подсистемы визуализации – непосредственно отрисовка визуальной сцены в браузере. Код всех основных функций встраивается в формируемый модулем визуализации код пустой визуальной сцены, тем самым наполняя ее объектами и событиями. Полученная визуальная сцена отображается при помощи браузера и принимает входные данные, определяющие ее поведение, образуя тем самым подсистему визуализации (1).
Оценим зависимость производительности формируемой визуальной сцены от ее сложности (количества составляющих объектов и элементов). В качестве примера рассмотрим упрощенную сцену промышленной зоны (рис. 9) и ее более детализированную версию (рис. 10).
Рис. 9. Упрощенная визуальная сцена промышленной зоны
Упрощенная сцена состоит из более чем 100 сложных объектов и более чем 400 простых элементов. Производительность такой модели составляет 60 FPS (frames per second, количество кадров в секунду, отображаемых на мониторе). В более детализированной модели количество сложных объектов возросло незначительно (с 106 до 119), а количество простых элементов – почти в 6 раз (с 419 до 2453) (рис. 10). При этом возросло время загрузки сцены, а производительность упала до 20 FPS.
Существует исследование, согласно которому минимальное значение частоты кадров, обеспечивающее плавное восприятие человеком отображения движения – 8 FPS [13]. Таким образом, предлагаемый метод обеспечивает достаточную производительность визуализации даже при возрастающей сложности модели.
Рис. 10. Детальная визуальная сцена промышленной зоны
8. Организация обмена данными
Для организации обмена данными между источником данных и подсистемой визуализации используется клиент-серверная архитектура. Классический вариант архитектуры обладает существенным недостатком – синхронным обменом данными, т.е. взаимодействием в рамках запроса и ответа. В том случае, когда может потребоваться интенсивная передача больших массивов данных через разные промежутки времени, это может вызвать существенное снижение производительности подсистемы визуализации.
Для решения этой проблемы предлагается использовать полнодуплексный протокол websocket, который позволяет осуществлять асинхронный обмен сообщениями между браузером и веб-сервером в режиме реального времени. Согласно предлагаемой архитектуре (рис. 11), websocket-сервер выступает посредником между источником данных и подсистемой визуализации, которая функционирует обособленно от средства разработки. При данной реализации клиентам (подсистемам визуализации) нет необходимости постоянно делать запросы серверу, проверяя, нет ли доступных данных от источника, который сам выступает в качестве инициатора.
Данные от источника передаются на сервер, откуда они адресно отправляются к соответствующей подсистеме визуализации. Это означает, что различные наборы данных могут распределяться между разными подсистемами, тем самым отражая разные аспекты визуализируемой модели.
Рис. 11. Схема клиент-серверного взаимодействия
Также websocket-сервер используется для передачи сообщений между самими подсистемами или обратной связи между подсистемой и источником данных.
Такая организация обмена данных требует наличия клиентского модуля у всех участников обмена. Для подсистемы визуализации он генерируется вместе со всеми основными функциями, но пользователю понадобится интегрировать его в состав системы моделирования, добавив соответствующую функцию в программный код системы.
Модуль клиентской составляющей протокола websocket (в данном случае приведен код на языке JavaScript, но также существуют реализации на других языках программирования) описывает создание специального JavaScript-объекта и объявляет 3 метода:
· установления соединения с сервером;
· закрытия соединения;
· получения сообщения.
Приведем пример кода клиентской части протокола (листинг 3).
<script>
ws = new WebSocket(“ws://localhost”);
ws.open = function()
{
alert(“Connection opened”)
};
ws.onmessage = function(event)
{
alert(“Message.data = ” + event.data);
};
ws.onclose = function()
{
alert(“Connection closed”);
};
</script>
Листинг 3. Фрагмент кода клиентской части протокола на языке JavaScript
Серверная реализация структурно отличается от клиентской части только лишь наличием механизма идентификации клиентов – присвоения идентификаторов новым пользователям, удалением из списка старых.
9. Оптимизация производительности
Для улучшения производительности процесса визуализации авторы предлагают ввести механизм ее динамической оптимизации. В частости, при снижении частоты кадров до порогового значения, все объекты на сцене перерисовываются с меньшей детализацией, что достигается уменьшением количества граней каждого объекта, в зависимости от введенного коэффициента сложности:
GrK = Gr * K,
где GrK – количество граней оптимизированного визуального объекта,
Gr – количество граней неоптимизированного визуального объекта,
K – коэффициент сложности.
При значении коэффициента, равном 1, детализация объекта будет максимальной, а при его снижении, например, с шагом 0,2, соответственно будет уменьшаться количество граней объекта, тем самым снижая его качество.
Предлагаемый механизм был проверен на тестовой сцене (рис. 12), состоящей из простейших объектов, с постепенным увеличением их количества с шагом в 1 тысячу. В качестве объектов для теста использовались простейшие сферы с количеством сегментов – 32 по вертикали и горизонтали. Выбор сферы в качестве объекта для теста обусловлен ее формой, наиболее показательной при снижении детализации.
Рис. 12. Набор объектов, отрисованных с разным коэффициентом сложности
Увеличение количества объектов до 6 тысяч, при значении коэффициента равным 1, показало снижение частоты кадров с 60 до 12 FPS. При снижении коэффициента сложности с 1 до 0,8 частота кадров увеличилась на 80% до 22 FPS. Потребовалось увеличить количество объектов до 10 тысяч, чтобы вновь достигнуть порогового значения. График показывает, что частота кадров снижается медленно, и изменение коэффициента сложности слабо влияет на изменение частоты кадров, вплоть до увеличения количества объектов до 13 тысяч и приближения частоты кадров к значению 9 FPS (рис. 13).
Рис. 13. График производительности тестовой сцены
На рисунке 12 приведены объекты, отображенные с разным коэффициентом сложности: слева направо, сверху вниз – от 1 до 0.2. Рисунок показывает, что существенная разница становится заметна лишь при переходе на объекты с коэффициентом 0,6 и менее. Необходимо заметить, что для удобства демонстрации объекты представлены в «каркасном» виде, в то время как при закрашенных полигонах отличие изображений было бы еще менее заметно.
На основе полученных результатов можно сделать вывод о том, что целесообразность подобного механизма оптимизации зависит от характера визуальной сцены в каждом отдельном случае, а его использование будет оправдано при наличии большого количества детализированных объектов. Также стоит принять во внимание форму самих используемых объектов (рис. 12). Сцена, состоящая преимущественно из простых прямоугольных объектов (например, моделирование землетрясения в городе [14]), не выиграет от введения коэффициента, так как для таких объектов невозможно снизить количество сегментов. Тогда как, например, модель завода с большой протяженностью трубопровода из-за характера формы труб наоборот сможет повысить свою производительность.
10. Заключение
В данной работе авторами были предложены основные принципы разработки программного средства, которое способно предоставить пользователям инструментарий для создания подсистем визуализации различного назначения.
Была описана формальная модель средства, его архитектура и все основные функциональные компоненты средства. Последовательно разобран процесс проектирования подсистемы визуализации на всех его основных этапах: онтологическое моделирование создание визуальных объектов; формирование правил построения визуальной сцены; генерация программного кода; выполнение сгенерированного кода сцены. Базовая функциональность всех основных программных модулей также была реализована авторами.
Также в работе были описаны основные принципы реализации процесса передачи данных от источника к подсистеме визуализации с использованием асинхронного протокола передачи данных.
Предлагаемое программное средство позволяет создавать пользовательские подсистемы визуализации, не прибегая к стороннему программному обеспечению и не обладая навыками программирования. При этом авторы отмечают, что такой унифицированный подход к визуализации имеет и отрицательную сторону – создаваемые визуальные сцены чаще всего имеют более слабую детализацию, чем при использовании профессиональных графических пакетов или средств.
Работа частично поддержана грантами РФФИ №16-37-00122 «Модели, методы и средства синтеза императивного описания пространственно-временных сцен на основе онтологий и порождающего программирования», №16-07-05641 «Разработка принципов, моделей и методов создания и поддержки интеллектуальных мультиагентных систем для прогнозирования техногенных чрезвычайных ситуаций» и № 15-37-20655 «Разработка моделей, методов и средств сервисно-ориентированной технологии синтеза баз знаний продукционных экспертных систем на основе трансформации концептуальных моделей».
Список литературы
1. Герасимов С.И., Бутова С.В. Съемка движущегося ракетного поезда. Научная визуализация. 2015. № 2. С. 12-20.
2. Рыбкина А.И., Бобков А.Е., Никифоров О.В., Пятыгина О.О. Программно-аппаратный комплекс для визуализации геофизических данных на сферическом экране. Научная визуализация. 2015. № 2. С. 38-49.
3. Турпалов В.Е., Гаврилов Н.И. Технологии трехмерной научной визуализации и геометрического моделирования в цифровой биомедицине. Научная визуализация. 2015. № 4. С. 27-43.
4. Грибова В.В., Петряева М.В., Федорищев Л.А. Разработка виртуального мира медицинского компьютерного обучающего тренажера. Дистанционное и виртуальное обучение. 2011. №9. С. 19-25.
5. Трухан И.А., Трухан Д.А. Визуализация учебной информации в обучении математике, ее значение и роль. Успехи современного естествознания. 2013. № 10. С. 113-115.
6. Рябинин К.В. Методы и средства разработки адаптивных мультиплатформенных систем визуализации научных экспериментов. дис. канд. физ.-мат. наук: 05.13.11. М., 2015. 207 с. URL: http://library.keldysh.ru/diss.asp?id=2015-ryabinin
7. Документация спецификации Web-based Graphics Library (WebGL). 2016. URL: https://www.khronos.org/registry/webgl/specs/latest/1.0/ (дата обращения: 10.03.2016).
8. Коршунов С.А., Николайчук О.А., Павлов А.И. Концепция программного средства визуализации результатов имитационного моделирования. Научная визуализация. 2016. №8. С.120-131.
9. Ryabinin K., Chuprina S. Development of Ontology-Based Multiplatform Adaptive Scientific Visualization System. Journal of Computational Science. Elsevier, 2015. Vol. 10. pp. 370-381.
10. Коршунов С.А. Онтологический подход к визуализации результатов имитационного моделирования. Сборник трудов VI Международной научно-технической конференции «Открытые семантические технологии проектирования интеллектуальных систем» OSTIS-2016 (Минск, Республика Беларусь, 18 февраля 22 февраля 2016 г.). Минск: БГУИР, 2016. С. 355-358.
11. Джамбруно М. Трехмерная (3D) графика и анимация. 2-е издание. Пер. с англ. М.: Вильямс, 2002. 640 с. [Giambruo M. 3D Graphics & Animation. 2nd ed. New Riders Press, 2002. 640 p.]
12. 3D Warehouse. URL: https://3dwarehouse.sketchup.com. (дата обращения: 10.07.2016).
13. Keval H., Sasse M.A. To catch a thief you need at least 8 frames per second: the impact of frame rates on user performance in a CCTV detection task. Proceedings of the 16th ACM international conference on Multimedia. ACM, 2008. pp. 941-944.
14. Kohei Fujita, Tsuyoshi Ichimura, Muneo Hori. A quick earthquake disaster estimation system with fast urban earthquake simulation and interactive visualization. Procedia Computer Science. 2014. Volume 29. pp.866-876.
VISUALIZATON SOFTWARE BASED ON WEBGL
S.A. Korshunov, O.A. Nikolaychuk, А.I. Pavlov
Matrosov Institute for System Dynamics and Control Theory of Siberian Branch of RAS, Irkutsk, Russia.
e-mail: grey.for@gmail.com, nicoly@icc.ru, asd@icc.ru
Аbstract
The paper describes the main principles of visualization software development, as well as implemented by this software approach, which is based on the use of ontologies to describe both the rendered domain, and the rules of its 3D-displaying. This approach allows the user to avoid programming the 3D-scene and describe it in terms of the research area.
The paper set out a formal model of a software tool, its architecture, basic modules and ontology structure. The process of visual scene design and creation is described, including the steps of ontology modelling, visual objects creation, formation of scene describing rules, code generation, visualization, organization of data exchange between visualization software and data source.
WebGL-based library was chosen as primary means for 3D graphics rendering, which allows to create visual scenes in the user's web browser. Examples of generated scenes and the question of its performance are also discussed in the article.
Keywords: visualization, ontology, simulation, modeling, computer graphics, webgl.
References
1. Gerasimov S.I., Butova S.V. Semka dvizhushhegosja raketnogo poezda [Photographing the moving sled train]. Scientific visualization. 2015. No. 2. pp.12-20. [In Russian]
2. Rybkina A.I., Bobkov A.E., Nikiforov O.V., Pjatygina O.O. Programmno-apparatnyj kompleks dlja vizualizacii geofizicheskih dannyh na sfericheskom jekrane [Hardware and software system for visualization of geophysical data on spherical screen]. Scientific visualization. 2015. No 2. pp. 38-49. [In Russian]
3. Turpalov V.E., Gavrilov N.I. Tehnologii trehmernoj nauchnoj vizualizacii i geometricheskogo modelirovanija v cifrovoj biomedicine [3D scientific visualization and geometric modeling in digital biomedicine]. Scientific visualization. 2015. No 4. pp. 27-43. [In Russian]
4. Gribova V.V., Petrjaeva M.V., Fedorishhev L.A. Razrabotka virtual'nogo mira medicinskogo komp'juternogo obuchajushhego trenazhera [The development of the virtual world of computer medical training simulator]. Distancionnoe i virtual'noe obuchenie [Distance and virtual learning]. 2011. No 9. pp. 19-25. [In Russian].
5. Truhan I.A., Truhan D.A. Vizualizacija uchebnoj informacii v obuchenii matematike, ee znachenie i rol' [Visualization of the educational information in the teaching of mathematics, its importance and role]. Uspehi sovremennogo estestvoznanija. 2013. No 10. pp. 113-115. [In Russian].
6. Ryabinin K.V. Metody i sredstva razrabotki adaptivnyh mul'tiplatformennyh sistem vizualizacii nauchnyh jeksperimentov. Diss. [Methods and tools for development of ontology-based multiplatform adaptive scientific visualization systems. Diss.]. 2015. 207 с. URL: http://library.keldysh.ru/diss.asp?id=2015-ryabinin. [In Russian].
7. Documentation of specification Web-based Graphics Library (WebGL). 2015. available at: https://www.khronos.org/registry/webgl/specs/latest/1.0/ (accessed: 10.07.2016).
8. Korshunov S.A., Nikolajchuk O.A., Pavlov A.I. Koncepcija programmnogo sredstva vizualizacii rezul'tatov imitacionnogo modelirovanija [Concept of simulation visualization software based on ontology approach]. Scientific visualization. 2016. No8. pp.120-131. [In Russian].
9. Ryabinin K., Chuprina S. Development of Ontology-Based Multiplatform Adaptive Scientific Visualization System. Journal of Computational Science. Elsevier, 2015. Vol. 10. P. 370-381.
10. Korshunov S. A. Ontology-based approach for visualization of simulation results. Sbornik trudov VI Mezhdunarodnoj nauchno-tehnicheskoj konferencii «Otkrytye semanticheskie tehnologii proektirovanija intellektual'nyh sistem» OSTIS-2016 [Open Semantic Techonologies for Intelligent Systems] (Minsk, Belarus, 18 22 feb. 2016.). Minsk: BGUIR, 2016. pp. 355-358. [In Russian].
11. Giambruo M. 3D Graphics & Animation. 2nd ed. New Riders Press, 2002. 640 p.
12. 3D Warehouse. URL: https://3dwarehouse.sketchup.com. (accessed: 10.07.2016).
13. Keval H., Sasse M.A. To catch a thief you need at least 8 frames per second: the impact of frame rates on user performance in a CCTV detection task. Proceedings of the 16th ACM international conference on Multimedia. ACM, 2008. pp. 941-944
14. Kohei Fujita, Tsuyoshi Ichimura, Muneo Hori. A quick earthquake disaster estimation system with fast urban earthquake simulation and interactive visualization. Procedia Computer Science. 2014. Volume 29. pp.866-876.