Дипломная (вкр): Автоматизированная система генерации приложений, использующих библиотеку OpenGL

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

Самыми широко используемыми можно назвать 3DS [3] и OBJ [4] форматы. Эти форматы поддерживаются всеми популярными графическими редакторами, такими как 3DS Max, Maya, Blender и т.д., а также разнообразными CAD системами.

К плюсам 3DS формата можно отнести:

)        поддерживается почти всеми редакторами трехмерной графики;

)        наиболее встречаемый формат, имеется множество готовых моделей в сети интернет;

)        является бинарным форматом, благодаря чему занимает меньше места на диске;

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

Минусами 3DS формата являются:

)        все поверхности полигональной сетки должны быть треугольниками;

)        имена текстур ограничены форматом записи DOS 8.3;

)        число вершин и полигонов в полигональной сетке ограничено 65536;

)        нормали вершин не могут быть сохранены в файле этого формата;

)        не поддерживаются направленные источники света.

К плюсам OBJ формата можно отнести:

)        является общепринятым форматом, поддерживается большим количеством редакторов графики (не только трехмерной);

)        имеет текстовый формат, благодаря чему легко читается и имеет возможность ручного редактирования;

)        хорошо описывает геометрию модели любой сложности.

Минусами OBJ формата являются:

)        представляет собой описание лишь геометрии модели;

)        не поддерживает иерархию в полигональной сетке.

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

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

С 3DS форматом все предстоит иначе. Учитывая его сложную структуру и то, что он является бинарным форматом, были разработаны неплохие отрытые библиотеки. Одним из примеров такой библиотеки является Lib3DS.DS [5] представляет собой бесплатную открытую кроссплатформенную библиотеку позволяющую легко управлять файлами 3DS формата. К основным возможностям данной библиотеки можно отнести:

)        работа в двух режимах процессора - big-endian и little-endian;

)        загрузка и сохранение:

a)         настроек атмосферы, фона, теней, окна просмотра;

b)      материалов;)        камер и света;)    полигональной сетки;) иерархии;)  ключевых кадров;

)        модули для работы с векторами и матрицами;

)        оценка ключевых кадров анимации.

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

Как известно, 3DS формат был разработан как формат-контейнер для сохранения модели и настроек среды, а значит, он не совсем подходит для прямого использования в программном коде. Именно по этой причине в данном программном продукте и разработан свой универсальный файл с описанием геометрии модели, специально оптимизированный для использования с библиотекой OpenGL.

Еще в 90-х годах создатель редактора трехмерной графики 3DS Max компания Autodesk, которая собственно и разработала 3DS формат, написала свою открытую библиотеку 3DSFTK [6], предоставляющую программистам возможность по управлению 3DS файлами. Но как случается с подобными утилитами, после написания этой библиотеки ее поддержка прекратилась. Поэтому она не совсем стабильная и имеется очень мало документации по ее использованию, особенно на русском языке.

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

1.3 Обоснование выбора технической платформы разрабатываемой системы

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

Минимальные требования, предъявляемые к комплексу технических средств:

)        процессор - 233 MHz;

)        оперативная память - 64 Mb RAM;

)        объем дисковой памяти - 1,5 GB свободного дискового пространства;

)        видеоадаптер и монитор - Super VGA 800x600;

Рекомендуемые требования к комплексу технических средств:

)        процессор - 300 MHz и выше;

)        оперативная память - 128 Mb RAM;

)        объем дисковой памяти - 1,5 GB свободного дискового пространства и выше;

)        видеоадаптер и монитор - Super VGA 800x600 и выше;

1.4 Обоснование выбора инструментальной среды разработки программного обеспечения

В качестве языка программирования для реализации данной работы был выбран язык С++. Этот выбор обусловлен следующими особенностями языка:

)        возможность генерации высокоэффективного программного кода;

)        поддерживаются различные стили и технологии программирования, включая традиционное директивное программирование, ООП, обобщённое программирование, метапрограммирование (шаблоны, макросы);

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

)        пользовательские функции-операторы позволяют кратко и ёмко записывать выражения над пользовательскими типами в естественной алгебраической форме;

)        имеется возможность работы на низком уровне с памятью, адресами;

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

Разрабатываемое программное обеспечение должно работать под управлением ОС Windows. Из существующих инструментальных сред разработки ПО с использованием языка C++ для ОС Windows была выбрана среда Microsoft Visual Studio 2005. Visual Studio 2005 представляет собой полный набор средств, помогающих ускорить процесс реализации замысла разработчика. К преимуществам Microsoft Visual Studio 2005 относятся:

)        удобное, продуманное рабочее место программиста;

)        наличие обширных справочных материалов для разработчика (MSDN);

)        гибкость программных средств, легкая достижимость требуемого результата;

)        среда, имеющая наибольшее распространение среди профессиональных разработчиков Windows-приложений;

)        возможность создания проектов любой сложности и объема;

)        огромное количество отдельных классов, компонентов, библиотек, написанных за последние 10-15 лет (повторная применимость кода);

)        удобные отладочные средства;

)        мощный оптимизирующий компилятор;

)        генерация каркаса приложения в зависимости от его предназначения и особенностей интерфейса.

1.5 Задачи выпускной работы

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

Для достижения поставленных целей необходимо решить следующие задачи:

)        рассмотреть структуру 3DS формата, выявить основные ее части;

)        рассмотреть структуру Obj формата, выявить основные ее части;

)        спроектировать свой универсальный формат хранения геометрии модели, необходимый для удобного и простого подключения к приложению;

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

)        разработать динамическую библиотеку (lib3do) выполняющую загрузку спроектированного универсального формата (далее 3DO) и предоставляющую простой интерфейс по манипуляции с ним:

a)         выполнить анализ задачи с целью выявления подзадач, которые должны быть решены;

b)      разработать алгоритмы решения выявленных подзадач;)  разработать архитектуру библиотеки и определить характер взаимосвязи программных единиц;)      выполнить кодирование, а также его отладку и тестирование библиотеки для подтверждения работоспособности созданного программного обеспечения.

)        разработать программный продукт выполняющий трансляцию входного файла (3DS или Obj) в свой спроектированный формат (3DO) и генерацию шаблона графического приложения:

a)         выполнить анализ задачи с целью выявления подзадач, которые должны быть решены;

b)      разработать алгоритмы решения выявленных подзадач;)  разработать архитектуру программного обеспечения и определить характер взаимосвязи программных единиц;)         выполнить кодирование приложения, а также его отладку и тестирование для подтверждения работоспособности созданного программного обеспечения.

2. Анализ задачи

В данном разделе производится детализация и анализ таких задач:

)        автоматизированная система генерации приложений, использующих библиотеку OpenGL;

)        шаблон графического приложения.

2.1 Анализ автоматизированной системы

.1.1 Анализ первого уровня детализации задачи

На первом уровне детализации программное приложение можно представить в виде трех основных блоков, представленных на рисунке 2.1.

Рисунок 2.1 - первый уровень детализации

Основными входными данными являются графические файлы, с описанием моделей в форматах поддерживаемых приложением - 3DS и Obj форматы. В последующих версиях планируется увеличение поддерживаемых форматов.

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

Универсальный 3DO файл основан на xml [7] формате и имеет следующую структуру:

<!-- заголовок файла -->

<3DO version=”1.0”>

<!-- дата создания файла -->

<created>

-03-19T18:31:50

</created>

<!-- дата изменения файла -->

<modified>

2012-03-19T18:31:50

</modified>

<!--/ блок описания геометрии объектов -->

<geometries>

<!-- описание геометрии определенного объекта -->

<geometry id="Name-mesh">

<!-- описание источника хранящего вершины объекта -->

<source id="Name-mesh-positions">

<!-- массив описывающий координаты вершин объекта -->

<source_array id="Name-mesh-positions-array" count="9">

.4375 -0.1640625 0.765625 -0.4375 0.1640625 0.765625

.5 0.09375 0.6875

</source_array>

<!-- дополнительные параметры -->

<technique_common>

<!-- описание доступа к массиву вершин -->

<accessor source=”#Name-mesh-positions-array” count=”3” stride=”3”>

<!-- координата X типа float -->

<param name="X" type="float"/>

<!-- координата Y типа float -->

<param name="Y" type="float"/>

<!-- координата Z типа float -->

<param name="Z" type="float"/>

</accessor>

</technique_common>

</source>

<!-- описание источника хранящего нормали к вершинам объекта -->

<source id="Name-mesh-normals-vertices">

<!-- массив описывающий координаты нормалей к вершинам объекта -->

<source_array id="Name-mesh-normals-vertices-array" count="9">

0.6649926 -0.2007524 0.719363 -0.6649926 -0.2007524 0.719363

.8294267 -0.303581 0.4689242

</source_array>

<!-- тоже что и раньше -->

<technique_common>

<accessor source=”#Name-mesh-normals-vertices-array” count=”3” stride=”3”>

<param name="X" type="float"/>

<param name="Y" type="float"/>

<param name="Z" type="float"/>

</accessor>

</technique_common>

</source>

<!-- описание источника хранящего нормали к граням объекта -->

<source id="Name-mesh-normals-faces">

<!-- массив описывающий координаты нормалей к граням объекта -->

<source_array id="Name-mesh-normals-faces-array" count="9">

0.6649926 -0.2007524 0.719363 -0.6649926 -0.2007524 0.719363

.8294267 -0.303581 0.4689242

</source_array>

<!-- тоже что и раньше -->

<technique_common>

<accessor source=”#Name-mesh-normals-faces-array” count=”3” stride=”3”>

<param name="X" type="float"/>

<param name="Y" type="float"/>

<param name="Z" type="float"/>

</accessor>

</technique_common>

</source>

<!-- описание вершин объекта -->

<vertices id="Name-mesh-vertices">

<!-- указание источника -->

<input semantic="POSITION" source="#Name-mesh-positions"/>

</vertices>

<!-- описание граней объекта -->

<polylist count="1">

<!-- указание источника для вершин граней -->

<input semantic="VERTEX" source="#Monkey-mesh-vertices"/>

<!-- указание источника для нормалей к граням -->

<input semantic="NORMAL" source="#Monkey-mesh-normals-faces"/>

<!-- описание количества вершин на каждой грани -->

<vcount>

</vcount>

<!-- описание индексов указывающих на вершины объекта -->

<p>

2 3

</p>

</polylist>

</geometry>

</geometries>

</3DO>

2.1.2 Анализ второго уровня детализации задачи

Структура рассматриваемой задачи на втором уровне детализации представлена на рисунке 2.2.

Рисунок 2.2 - второй уровень детализации

2.1.2.1 Ввод данных

Назначение задачи “Ввод данных” состоит в указании пути к файлу с описанием модели (3DS или Obj), который далее будет преобразован в универсальный 3DO файл.

Также если пользователь захочет сгенерировать шаблон графического приложения, то необходимо указать имя этого приложения и путь по которому оно будет сохранено. Еще необходимо указать путь к файлу 3DO для его загрузки и вывода в коде шаблона.