Обзор существующих решений


Скачать 0.66 Mb.
Название Обзор существующих решений
страница 4/10
Тип Обзор
rykovodstvo.ru > Руководство эксплуатация > Обзор
1   2   3   4   5   6   7   8   9   10

4.2 Архитектура приложения



3D сцена в библиотеке Ogre 3D имеет древовидную структуру, корневым элементом которой является главный узел сцены (RootSceneNode). Каждый узел сцены может иметь своих потомков (SceneNode). Таким образом, все сцены привязаны к главному узлу сцены.

К нескольким потомкам главного узла сцены необходимо привязать сцену в виде комнаты, в которой будут закреплены определённые 3D модели.

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

Архитектура приложения, в соответствии с рисунком 6, состоит из следующих классов:

Менеджер сцены – ключевой класс, отвечающий за рендер сцены, настройки расположения 3D моделей на сцене и анимации 3D моделей.

Входные данные – класс, который отвечает за считывание входных данных пользователя: обработка клика мышки для определения попадания луча (экземпляр класса Ray) на 3D модель, обработка клавиатуры.

Менеджер текстов – класс, в котором хранятся все тексты приложения. Также в нём реализована подгрузка текста с описанием 3D модели из файла.

Менеджер настроек – класс, отвечающий за конфигурацию приложения, подгрузку ресурсов приложения и за настройку сторонней графической библиотеки.

Графический интерфейс – отвечает за настройку графического интерфейса пользователя, а также за графические эффекты.

Менеджер камеры – менеджер настроек движения камеры.
архитектура

Рисунок 6 – Архитектура приложения
При разработке архитектуры приложения используются следующие шаблоны проектирования:

Faсade – применяется для абстрагирования классов графического интерфейса, менеджера настроек, менеджера сцены, входных данных.

Singleton – для обеспечения глобального доступа к экземплярам классов менеджера текстов, менеджера сцены, менеджера камеры.

Listener – для обеспечения взаимодействия классов. Реализуется интерфейс с помощью которого шаблон получает оповещения от классов входных данных и графического интерфейса [4].

4.3 Разработка кода



В первую очередь была проведена настройка сцены для дальнейшей разработки. Сюда относится подготовка движка к работе, подключение библиотек, плагинов и ресурсов, настройка сцены. Программный код представлен в приложении Б.

Для корректного отображения элементов на 3D сцене необходимо настроить следующие компоненты:

  • ресурсы

  • камера

  • сцена

  • покадровый рендеринг графики

  • конфигурация (подгрузка плагинов и ресурсов)

  • наблюдатели (Observed)

4.3.1 Настройка подгружаемых ресурсов


Подгружаемые ресурсы передаются в Ogre из конфигурационного файла, в котором указаны пути к файлам, нужные в целях рендера. Как правило, это конфигурационный файл ресурсов, включающий в себя шрифты, 3D модели, файлы партиклов и так далее.
FileSystem=../../media/fonts

FileSystem=../../media/models

FileSystem=../../media/particle
А также конфигурационный файл плагинов, включающий в себя плагины графических библиотек DirectX, OpenGL, плагин партикловых эффектов и так далее.
Plugin=RenderSystem_Direct3D9_d

Plugin=RenderSystem_GL_d

Plugin=Plugin_ParticleFX_d
Таким образом, нужно указать приложению, какие файлы требуется подгружать на старте программы. Создаётся экземпляр класса Root, являющийся корневым классом и представляет собой отправную точку клиентского приложения, с помощью которого можно получить доступ к основам системы, а именно системам рендеринга, управлению конфигурациями, логированию и другим классам системы [10]. Также создаётся два экземпляра для работы с конфигурационными файлами плагинов и ресурсов, загружаемые при помощи функции load, которой передаются соответствующие названия файлов, загружает данные файлы.

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

4.3.2 Покадровый рендеринг графики и шаблон наблюдатель


В начале создаётся функция FrameListener, отвечающая за прослушивание каждого кадра на экране рендера. FrameListener основан на паттерне наблюдателя (Observed). В функции создаётся список параметров для OIS (объектно-ориентированная система ввода), затем нужно получить от OGRE хэндл окна (дескриптор в виде числа, с помощью которого идентифицируется ресурс), в котором в текущий момент происходит рендеринг графики. Далее в систему ввода передаётся хэндл окна рендера и описываются функции обратного вызова (callback) для настройки считывания действий пользователя с мыши и клавиатуры. В завершение этой функции добавляется наблюдатель на текущее окно, на случай, если нужно обработать, например, изменение размера экрана рендера, то есть разворачивание окна.

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

Пример обработки клавиши ESC.
if (Keyboard->isKeyDown(OIS::KC_ESCAPE))

return false;

4.3.3 Создание сцены, камеры и порта просмотра


Порт просмотра используется для отрисовки трёхмерного содержимого в 2D окне. Порт просмотра напрямую привязан к камере.

Для создания и дальнейшей настройки сцены, необходимо создать экземпляр класса менеджера сцены, способный управлять объектами, находящимися на сцене.

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

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

4.3.4 Загрузка и установка заданных ресурсов


Отображение объекта на сцене требует явного описания его параметров в коде. Для того чтобы автоматизировать этот процесс, нужно знать какие 3D модели находятся в файле описания ресурсов и затем во время запуска приложения описать параметры всех 3D моделей. Таким образом после запуска все 3D модели появятся на сцене.

Для того чтобы узнать какие модели загружаются при запуске, создан вектор строкового типа, в который записываются названия подгружаемых 3D моделей. Так как все модели упаковываются в zip архив перед загрузкой на сцену, они программно отыскиваются по расширению .zip.

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

Поиск работает следующим образом: если в текущей строке есть подстрока «.zip», то с конца строки доходим до первого слеша (корневая директория файла) и далее считывается имя архива. Как правило имя архива должно совпадать с названием 3D модели. После завершения считывания имени оно заносится в созданный вектор.
char result[100];

if ( std::strstr(stringToChar, ".zip") )

{

int len = strlen(stringToChar);

int i = 0;
for(i = len; i > 0 ; i--)

{

if ( stringToChar[i-1] == '/')

{

break;

}

}

int res = 0;
for(int j = i; j < len ; j++)

{

result[res++] = stringToChar[j];
if ( stringToChar[j+1] == '.')

{

break;

}
}

myVector.push_back( std::string(result) );

}

Далее требуется настроить параметры всех моделей, занесенных в вектор. Для того чтобы прикрепить 3D модель к сцене, Ogre3D использует узел сцены, являющийся дочерним элементов корневого узла сцены. Чтобы узел стал активным, нужно прикрепить к созданному узлу сцены сущность в виде 3D модели.

Так как требуется прикрепить сразу множество моделей на сцену, прикрепление реализовано в цикле. Проходим циклом по всему вектору, забираем из каждой позиции вектора название модели и создаём сущность с таким же именем и конкатенируем .mesh , так как в архиве файл 3D модели имеет именно такое расширение. Далее создаём узел сцены с именем модели, чтобы в дальнейшем была возможность обратиться к конкретного узлу по его имени и устанавливаем позицию узла на сцене.
for(int i = 0; i < myVector.size(); i++)

{

Ogre::Entity* lEntity = mSceneMgr->createEntity( myVector[i] + ".mesh" );

lNode = mSceneMgr->getRootSceneNode()->createChildSceneNode(myVector[i]);

lNode->attachObject(lEntity);

lNode->setPosition(0, 0, 0);

}

4.3.5 Выделение моделей на сцене, управление камерой


Для взаимодействия пользователя с объектами на сцене, нужно реализовать обратную связь с пользователем. Взаимодействие со сценой происходит при помощи мыши, при нажатии на объект клавишей мыши, камера «подлетает» к выделенному объекту.

В целях реализации обратной связи необходимо определить нажатие пользователем на 3D модель на сцене. Для этого используется экземпляр класса Ray (луч), выпущенный из позиции нажатия мыши на экран. Также создаётся экземпляр очереди, связанный с лучом, в который записываются все объекты, через которые прошёл луч. В итоге, в цикле проходим по всей очереди и проверяем, является ли какой-либо из объектов, на который упал луч, одной из наших подгруженных моделей. Если объект является нашей моделью, то выделяем его. При возвращении камеры на исходную позицию снимаем выделение с 3D модели.

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

Возвращение камеры на исходную позицию происходит аналогичным образом. Исходная позиция камеры предустановлена в коде.
Ogre::Vector3 needPosition = SceneMgr

->getSceneNode(myVector[i])->getPosition() +

Ogre::Vector3(200,50,50);

Camera->move( (needPosition - Camera->getPosition() ) * fe.timeSinceLastFrame);

Camera->lookAt(SceneMgr->getSceneNode(myVector[i]) ->getPosition() );

4.3.6 Сохранение состояния программы


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

Сохраняются следующие данные по всем осям: позиция модели в пространстве и масштаб модели, также сохраняется угол поворота модели.

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

{

xml_name_model->QueryDoubleAttribute("xPosition", &xPos);

xml_name_model->QueryDoubleAttribute("yPosition", &yPos);

xml_name_model->QueryDoubleAttribute("zPosition", &zPos);

locationVector.x = xPos;

locationVector.y = yPos;

locationVector.z = zPos;

xml_name_model->QueryDoubleAttribute("xScale", &xScale);

xml_name_model->QueryDoubleAttribute("yScale", &yScale);

xml_name_model->QueryDoubleAttribute("zScale", &zScale);

scaleVector.x = xScale;

scaleVector.y = yScale;

scaleVector.z = zScale;

xml_name_model->QueryDoubleAttribute("rotate", &rotateModel);

rotate = rotateModel;

}

if (addNew)

{

file_settings->LinkEndChild(xml_name_model);

std::srand( std::time(NULL) );

locationVector.x = 0;

locationVector.y = 0;

locationVector.z = std::rand()%300;

xml_name_model->SetDoubleAttribute("xPosition", locationVector.x );

xml_name_model->SetDoubleAttribute("yPosition", ЯlocationVector.y );

xml_name_model->SetDoubleAttribute("zPosition", locationVector.z );

scaleVector.x = 1;

scaleVector.y = 1;

scaleVector.z = 1;

xml_name_model->SetDoubleAttribute("xScale", scaleVector.x);

xml_name_model->SetDoubleAttribute("yScale", scaleVector.y);

xml_name_model->SetDoubleAttribute("zScale", scaleVector.z);

rotate = 0.0;

xml_name_model->SetDoubleAttribute("rotate", rotate);

file_settings->SaveFile();

}
Таким образом, в xml файле с параметрами модели всегда хранится актуальная информация о параметрах для каждой оси, кроме угла поворота, который не зависит от оси.



1   2   3   4   5   6   7   8   9   10

Похожие:

Обзор существующих решений icon Описание предметной области
Обзор существующих программных продуктов систем обработки данных c использованием ip-телефонии 7
Обзор существующих решений icon Метода очистки
Целью настоящей работы является разработка технических решений по усовершенствованию существующих методов зачистки резервуаров с...
Обзор существующих решений icon Генеральный план совмещенный с проектом планировки пояснительная...
Выявление проблем градостроительного развития территории поселения на основе анализа параметров городской среды, существующих ресурсов...
Обзор существующих решений icon Обзор
Оспаривание решений и действий (бездействия) органов государственной власти, органов местного самоуправления, должностных лиц, государственных...
Обзор существующих решений icon Экспериментальная медицина и детская неврология обзор
Системный обзор вмешательств у детей с церебральным параличом: статус доказательности
Обзор существующих решений icon «Выполнение работ по развитию и оказание услуг по сопровождению Федерального...
Целью работы является анализ справочников фргу на соответствие следующим критериям: актуальность и полнота существующих справочных...
Обзор существующих решений icon Теоретические основы анализа и планирования разработки управленческих решений 5
Методы планирования, используемые при разработке и принятии управленческих решений в организации 9
Обзор существующих решений icon Обзор текущего состояния и особенности государственной инновационной политики
Периодический обзор инновационной деятельности стран Европы, Америки, Азии и Африки, СНГ
Обзор существующих решений icon Методические указания Ростов-на-Дону
Целью данного курса является формирование представления о процессе принятия решений, навыков анализа ситуации при принятии решений,...
Обзор существующих решений icon Экспериментальное народное самолетостроение 2 Глава Предварительный анализ и выбор решений 2
«летающих решений», некоего ковра-самолета «небесного катера» для отдыха и путешествий, не требующего летных удостоверений и сертификации....
Обзор существующих решений icon Марка Сергеева государственные и муниципальные библиотеки иркутской...
Г 72 ежегод аналит обзор / Иркут обл гос универс науч б-ка им. И. И. Молчанова-Сибирского
Обзор существующих решений icon Решение это выбор альтернативы
Чтобы оказать вам помощь в этом, ниже мы рассмотрим типы решений, принимаемых управляющими, используемые способы, научные методы...
Обзор существующих решений icon 2 Анализ выполнения решений международных документов/решений, принятых...
На Рис. 133 наглядно представлена оценка Азербайджанской республики с точки зрения реализации основных направлений Плана действий...
Обзор существующих решений icon Учебное пособие. М.: Издательство "Март", 2004. Предыдущая
Моделирование как метод теории принятия решений и анализ ряда конкретных моделей предмет четвертой части. Приводятся методы принятия...
Обзор существующих решений icon Рабочая программа учебной дисциплины б. 3 Методы принятия управленческих...
Будущий менеджер должен научиться правильно применять готовые компьютерные программы, хорошо разработанную технику анализа количественных...
Обзор существующих решений icon Инструкция по эксплуатации на английском языке
Когда то я уже писал обзор на проектор Unic uc40 и когда увидел BlitzWolf (он же unic uc46) то решил взять его на обзор, что бы посмотреть...

Руководство, инструкция по применению




При копировании материала укажите ссылку © 2024
контакты
rykovodstvo.ru
Поиск