Размещено на http://www.allbest.ru/

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

1. ПРЕДПРОЕКТНЫЕ ИССЛЕДОВАНИЯ

1.1 Описание предметной области задачи автоматизации

1.2 Анализ прототипов системы

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

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

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

2. АНАЛИЗ ЗАДАЧИ

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

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

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

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

2.2 Анализ шаблона графического приложения

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

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

3. РАЗРАБОТКА АЛГОРИТМОВ РЕШЕНИЯ ЗАДАЧИ

3.1 Автоматизированная система генерации приложений

3.1.1 Алгоритм решения задачи “Ввод данных”

3.1.2 Алгоритм решения задачи “Конвертация файла”

3.1.3 Алгоритм решения задачи “Генерация шаблона”

3.2 Шаблон графического приложения

3.2.1 Алгоритм решения задачи “Инициализация OpenGL”

3.2.2 Алгоритм решения задачи “Загрузка 3D файла”

3.2.3 Алгоритм решения задачи “Вывод 3D файла на экран”

4. СИНТЕЗ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

4.1 Архитектура программного обеспечения

4.2 Информационное пространство системы

4.3 Интерфейс пользователя

5. ТЕСТИРОВАНИЕ СИСТЕМЫ

6. ОЦЕНКА ЭКОНОМИЧЕСКОЙ ЭФФЕКТИВНОСТИ ПРИМЕНЕНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ И ОПРЕДЕЛЕНИЕ ЕГО ЦЕНЫ

6.1 Порядок расчета и анализа экономической эффективности

6.2 Расчет экономической эффективности применения программного обеспечения и определение его цены

7. ОХРАНА ТРУДА

7.1 Характеристика рабочего места

7.2 Выявление и анализ опасных и вредных эксплуатационных факторов, действующих в рабочей зоне проектируемого изделия

7.3 Разработка мероприятий по предотвращению или ослаблению возможного воздействия опасных и вредных эксплуатационных факторов на работающих

7.4 Обеспечение экологической безопасности функционирования проектируемого объекта

Список использованной литературы

ВВЕДЕНИЕ

Сейчас трёхмерные изображения можно увидеть везде, начиная от компьютерных игр и заканчивая системами моделирования в реальном времени. Раньше, когда трёхмерная графика существовала только на суперкомпьютерах, не существовало единого стандарта в области графики. Все программы писались с "нуля" или с использованием накопленного опыта, но в каждой программе реализовывались свои методы для отображения графической информации. С приходом мощных процессоров и графических ускорителей трёхмерная графика стала реальностью для персональных компьютеров. Но в тоже время производители программного обеспечения столкнулись с серьёзной проблемой - это отсутствие каких-либо стандартов, которые позволяли писать программы, независимые от оборудования и операционной системы. Одним из первых таких стандартов, существующий и по сей день, является OpenGL [1].

OpenGL - это графический стандарт в области компьютерной графики. На данный момент он является одним из самых популярных графических стандартов во всём мире. Ещё в 1982 г. в Стенфордском университете была разработана концепция графической машины, на основе которой фирма Silicon Graphics в своей рабочей станции Silicon IRIS реализовала конвейер рендеринга. На основе библиотеки IRIS GL, в 1992 году был разработан и утверждён графический стандарт OpenGL. Создатели OpenGL - это крупнейшие фирмы выпускающие как оборудование, так и программное обеспечение: Silicon Graphics, Inc., Microsoft, IBM Corporation, Sun Microsystems, Inc., Digital Equipment Corporation (DEC), Evans & Sutherland, Hewlett-Packard Corporation, Intel Corporation и Intergraph Corporation.

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

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

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

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

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

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

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

Данная выпускная работа состоит из трех частей:

1) основная часть;

2) экономическая часть;

3) вопросы безопасности жизнедеятельности.

В основной части выпускной работы содержатся такие разделы:

1) предпроектные исследования;

2) анализ задачи;

3) разработка алгоритмов решения задачи;

4) синтез программного обеспечения;

5) тестирование системы.

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

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

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

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

В разделе «Тестирование» описываются примеры, подтверждающие работоспособность созданного программного обеспечения.

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

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

1. Предпроектные исследования

1.1 Описание предметной области задачи автоматизации

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

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

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

Поэтому было принято решение стандартизировать метод доступа к графической аппаратуре на уровне программного интерфейса.

Таким образом, появился программный интерфейс OpenGL, который стандартизирует доступ к графической аппаратуре путём смещения ответственности за создание аппаратного драйвера на производителя графического устройства. Это позволило разработчикам программного обеспечения использовать более высокий уровень абстракции от графического оборудования, что значительно ускорило создание новых программных продуктов и снизило на них затраты.

OpenGL переводится как «Открытая Графическая Библиотека» (Open Graphics Library), это означает, что OpenGL - это открытый и мобильный стандарт. Программы, написанные с помощью OpenGL можно переносить практически на любые платформы, получая при этом одинаковый результат, будь это графическая станция или суперкомпьютер. OpenGL освобождает программиста от написания программ для конкретного оборудования. Если устройство поддерживает какую-то функцию, то эта функция выполняется аппаратно, если нет, то библиотека выполняет её программно.

Что же представляет из себя OpenGL? С точки зрения программиста OpenGL - это программный интерфейс для графических устройств, таких как графические ускорители. Он включает в себя около 150 различных команд, с помощью которых программист может определять различные объекты и производить рендеринг. Говоря более простым языком, вы определяете объекты, задаёте их местоположение в трёхмерном пространстве, определяете другие параметры (поворот, масштаб, ...), задаёте свойства объектов (цвет, текстура, материал, ...), положение наблюдателя, а библиотека OpenGL позаботится о том, чтобы отобразить всё это на экране. Поэтому можно сказать, что библиотека OpenGL является только воспроизводящей (Rendering), и занимается только отображением 3D объектов.

На данный момент OpenGL - одна из наиболее популярных графических библиотек, предоставляющих возможность реализовывать сложные задачи с 3D объектами у себя в программе. Ее главным конкурентом является DirectX [2] - коммерческий проект, изначально нацеленный на разработку видеоигр. Благодаря правильной рекламной компании от Microsoft и тому, что платформа Windows на данный момент является самой распространенной, DirectX завоевал большую популярность. Новые версии этой библиотеки используют самые передовые достижения в графической индустрии. Множество производителей видеокарт аппаратно поддерживают ее спецификацию. Но, не смотря на все эти преимущества, OpenGL имеет один главный плюс - открытость и кроссплатформенность. Благодаря этому OpenGL независим от языка программирования и используется на многих платформах, а также во многих тяжелых приложениях, таких как САПР системы. Разработка OpenGL не прекращается и на данный момент ее последняя версия (4.2) ничем не уступает по возможностям DirectX 11.

К преимуществам OpenGL можно отнести:

1) производительность - с самого начала в OpenGL была заложена "крайне желательная" возможность отрисовки динамических сцен;

2) ортогональность - по возможности все функции OpenGL являются ортогональными, то есть независимыми;

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

4) интероперабельность - в сетевом окружении важно передавать данные между разными платформами;

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

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

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

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

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

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

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

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

Основными данными, описывающими 3D модель, являются:

1) список вершин;

2) список граней (треугольники, четырехугольники);

3) список нормалей;

4) материалы граней;

5) текстурные координаты;

6) другие специфические каждому редактору блоки.

1.2 Анализ прототипов системы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

b) материалов;

c) камер и света;

d) полигональной сетки;

e) иерархии;

f) ключевых кадров;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

b) разработать алгоритмы решения выявленных подзадач;

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

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

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

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

b) разработать алгоритмы решения выявленных подзадач;

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

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

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

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

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

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

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

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

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

Размещено на http://www.allbest.ru/

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

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

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

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

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

<3DO version=”1.0”>

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

<created>

2012-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">

0.4375 -0.1640625 0.765625 -0.4375 0.1640625 0.765625

0.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

0.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

0.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>

4

</vcount>

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

<p>

1 2 3

</p>

</polylist>

</geometry>

</geometries>

</3DO>

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

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

Размещено на http://www.allbest.ru/

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

2.1.2.1 Ввод данных

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

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

2.1.2.2 Конвертация файла

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

Входными данными задачи являются:

1) путь к конвертируемому файлу (3DS или Obj);

2) путь и имя получаемого файла (3DO).

Структура исходного 3DO файла была описана выше.

К выходным данным относится полученный универсальный 3DO файл.

2.1.2.3 Генерация шаблона

Назначение задачи “Генерация шаблона” состоит в получении каркаса приложения используемого в дальнейшем для разработки несложных графических программ.

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

Входными данными задачи являются:

1) путь и имя генерируемого шаблона;

2) путь к универсальному 3DO файлу.

К выходным данным относится полученный каркас графического приложения.

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

Рассмотрим структуру задачи “Конвертация файла” (рисунок 2.3).

2.1.3.1 Загрузка файла для конвертации

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

Входными данными задачи являются путь и имя универсального 3DO файла.

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

Размещено на http://www.allbest.ru/

Рисунок 2.3 - структура задачи “Конвертация файла”

2.1.3.2 Расчет недостающих данных

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

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

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

Выходными данными являются рассчитанные нормали (вершинные и/или к граням).

2.1.3.3 Сохранение данных в 3DO формате

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

Входными данными является полное описание геометрии объектов, хранимое во внутренних структурах приложения, а также путь и имя 3DO файла.

Выходными данными является файл в 3DO формате, описывающий геометрию объектов.

Рассмотрим структуру задачи “Генерация шаблона” (рисунок 2.4).

Размещено на http://www.allbest.ru/

Рисунок 2.4 - структура задачи “Генерация шаблона ”

2.1.3.4 Настройка параметров шаблона

К задаче “Настройка параметров шаблона” относится:

1) указание пути и имени 3DO файла;

2) указание пути по которому шаблон будет сохранен.

2.1.3.5 Создание и сохранение шаблона

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

Готовый шаблон представляет собой проект выполненный в Microsoft Visual Studio 2005 на базе MFC Application.

Входными данными являются настройки шаблона.

К выходным данным относится полученный после конфигурирования шаблон.

2.2 Анализ шаблона графического приложения

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

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

Размещено на http://www.allbest.ru/

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

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

К выходным данным относится отображенный на экране выбранный 3D файл.

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

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

Размещено на http://www.allbest.ru/

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

2.2.2.1 Инициализация OpenGL

Назначение задачи “Инициализация OpenGL” состоит в начальной инициализации внутренних данных библиотеки OpenGL. Инициализация представляет собой следующие шаги:

1) установка формата пикселей;

2) создание контекста отображения;

3) выбор текущего контекста отображения.

2.1.2.2 Загрузка 3D файла

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

Входными данными задачи являются путь и имя 3D файла.

К выходным данным относятся загруженные в память приложения данные о геометрии модели из выбранного файла.

2.1.2.3 Вывод 3D файла на экран

Назначение задачи “Вывод 3D файла на экран” состоит в отображении на экране средствами библиотеки OpenGL геометрии объектов загруженных ранее из 3D файла.

При выводе пользователь имеет возможность задать некоторые настройки, влияющие на отображение объектов на экране.

3. Разработка алгоритмов решения задачи

Этот раздел содержит описание алгоритмов решения следующих задач:

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

a) ввод данных;

b) конвертация файла;

c) генерация шаблона.

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

a) инициализация OpenGL;

b) загрузка 3D файла;

c) вывод 3D файла на экран.

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

3.1 Автоматизированная система генерации приложений

3.1.1 Алгоритм решения задачи “Ввод данных”

Целью задачи “Ввод данных” является получение исходных данных необходимых для получения 3DO файла или шаблона приложения. Для достижения данной цели нужно выполнить следующие действия:

1) для конвертации файла:

a) осуществить указание пути к конвертируемому файлу (3DS или Obj);

b) осуществить указание пути и имени получаемого файла (3DO).

2) для генерации шаблона:

a) задать имя шаблона;

b) указать путь к 3DO файлу;

c) указать путь по которому шаблон будет сохранен.

3.1.2 Алгоритм решения задачи “Конвертация файла”

3.1.2.1 Алгоритм решения задачи “Загрузка файла для конвертации”

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

Основными этапами этой задачи являются:

1) открытие файла для чтения;

2) определение типа файла - либо по расширению, либо по заголовку;

3) чтение и интерпретация данных из файла:

a) чтение данных о координатах вершин;

b) чтение данных об индексах граней;

c) чтение данных о нормалях к граням (для Obj формата).

4) сохранение прочитанных данных во внутренние структуры;

5) закрытие файла.

3.1.2.2 Алгоритм решения задачи “Расчет недостающих данных”

Результатом выполнения задачи “Расчет недостающих данных” будет получение нормалей в каждой вершине и ко всем граням модели.

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

Для определения вектора нормали к плоскости достаточно иметь координаты трех точек принадлежащих этой плоскости. На рисунке 2.1 схематически показано получение такой нормали.

Размещено на http://www.allbest.ru/

Рисунок 2.1 - Нормаль к плоскости

детализация файл данные графический

По определению векторное произведение двух векторов есть вектор перпендикулярный плоскости определенной их координатами. Исходя из этого свойства нужный нам вектор нормали n можно представить как векторное произведение векторов ab и bc:

n = (bc, ab) (1.1)

где n - вектор нормали;

ab, bc - векторы перпендикулярные n.

Используя правило треугольника и зная соответствующие вектора a, b и c получим вектора ab и bc:

ab = b - a (1.2)

bc = b - c (1.3)

Таким образом, определение нормали к грани модели сводится к простым операциям над векторами.

Чтобы привести вектор нормали к единичной длине необходимо разделить вектор на его норму (длину):

n1 = n / |n| (1.4)

где n1 - вектор единичной длины;

n - вектор нормали;

|n| - длина вектора нормали.

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

Как видно поиск нормалей в вершинах может занять некоторое время, поэтому хранение их в 3DO файле оправданно, и сильно сэкономит предварительную инициализацию.

3.1.2.3 Алгоритм решения задачи “Сохранение данных в 3DO формате”

Результатом данной задачи будет получение 3DO файла, описывающего большинство параметров геометрии объектов (вершины, грани, нормали).

Алгоритм решения можно разделить на такие этапы:

1) открытие файла для записи;

2) запись геометрии объектов в файл с учетом структуры 3DO формата:

a) запись координат вершин;

b) запись координат нормалей в вершинах;

c) запись координат нормалей к граням;

d) запись количества вершин в каждой грани;

e) запись индексов граней;

3) закрытие файла.

3.1.3 Алгоритм решения задачи “Генерация шаблона”

3.1.3.1 Алгоритм решения задачи “Настройка параметров шаблона”

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

1) имя шаблона;

2) путь к шаблону;

3) путь и имя 3DO файла.

3.1.3.2 Алгоритм решения задачи “Создание и сохранения шаблона”

В результате проведения данной задачи будет получен сконфигурированный шаблон графического приложения.

Алгоритм “Создания и сохранения шаблона” подразумевает следующие пункты:

1) копирование файлов шаблона по указанному пути;

2) копирование 3DO файла.

3.2 Шаблон графического приложения

3.2.1 Алгоритм решения задачи “Инициализация OpenGL”

Целью задачи “Инициализация OpenGL” является начальная инициализация OpenGL машины. Для достижения данной цели нужно выполнить следующие действия:

1) установка формата пикселей;

2) создание контекста отображения;

3) выбор текущего контекста отображения.

3.2.2 Алгоритм решения задачи “Загрузка 3D файла”

Целью задачи “Загрузка 3D файла” является загрузка геометрии объектов из выбранного 3D файла.

Основными этапами этой задачи являются:

1) открытие файла для чтения;

2) определение типа файла - либо по расширению, либо по заголовку;

3) чтение и интерпретация данных из файла:

a) чтение данных о координатах вершин;

b) чтение данных об индексах граней;

c) чтение данных о нормалях к граням;

d) чтение данных о нормалях в вершинах.

4) сохранение прочитанных данных во внутренние структуры;

5) закрытие файла.

3.2.3 Алгоритм решения задачи “Вывод 3D файла на экран”

Целью задачи “Вывод 3D файла на экран” является отображении на экране средствами библиотеки OpenGL геометрии объектов загруженных ранее из 3D файла.

Основными этапами этой задачи являются:

1) настройка состояния отображения OpenGL окна;

2) вывод 3D объектов с помощью функций OpenGL.

4. Синтез программного обеспечения

4.1 Архитектура программного обеспечения

Для создания программного обеспечения в данной аттестационной работе используется язык программирования C++ и инструментальная среда разработки Microsoft Visual Studio 2005. Все создаваемые с помощью Microsoft Visual Studio 2005 приложения являются проектами. Студия предоставляет возможность создавать каркасы проектов при помощи генераторов приложений - мастеров. Мастер генерирует шаблон проекта, на основании которого, впоследствии, создается приложение. Также мастер предоставляет структуру программы, основные меню, панели инструментов, значки и т.д. Это позволяет, создав каркас приложения, сразу перейти непосредственно к программированию его функциональности.

Каркас проекта создан при помощи стандартного генератора приложений Application Wizard на основе шаблона MFC Application. Шаблон приложения MFC Application - является основой для стандартных приложений Windows.

В состав созданного при помощи Application Wizard проекта с именем GenOGLApp входят следующие файлы:

1) GenOGLApp.h - заголовочный файл, содержащий описание класса отвечающего за начальную инициализацию и создание главного окна проекта;

2) GenOGLApp.cpp - содержит реализацию выше описанного класса;

3) MainFrm.h - содержит описание класса отвечающего за внешний вид главного окна проекта;

4) MainFrm.cpp - содержит реализацию выше описанного класса;

5) GenOGLAppDoc.h - описывает класс хранящий основные данные проекта;

6) GenOGLAppDoc.cpp - содержит реализацию выше описанного класса;

7) GenOGLAppView.h - содержит описание класса отвечающего за отображение в главном окне проекта данных из предыдущего класса;

8) GenOGLAppView.cpp - содержит реализацию выше описанного класса;

9) Camera.h - отвечает за описание класса предоставляющего реализацию камеры для просмотра OpenGL окна;

10) Camera.cpp - содержит реализацию выше описанного класса;

11) ConvertDlg.h - содержит описание класса окна диалога отвечающего за конвертацию 3D файла в 3DO формат;

12) ConvertDlg.cpp - содержит реализацию выше описанного класса;

13) GenerateDlg.h - содержит описание класса окна диалога отвечающего за создание шаблона OpenGL приложения;

14) GenerateDlg.cpp - содержит реализацию выше описанного класса;

15) StdAfx.h - используется для создания пре-компилированного файла заголовка.

Основными классами приложения являются:

1) CGenOGLApp - главный класс приложения, наследуется от стандартного класса CWinApp. Выполняет начальную инициализацию и создание главного окна проекта;

2) СMainFrame - класс наследуемый от CFrameWnd, задает внешний вид главного окна проекта;

3) CGenOGLAppDoc - класс наследуемый от CDocument, хранит основные данные проекта;

4) CGenOGLAppView - класс наследуемый от CView, выполняет начальную инициализации OpenGL и отвечает за вывод данных хранящихся в предыдущем классе;

5) CCamera - класс, реализующий возможности камеры для просмотра объектов в OpenGL окне;

6) CConvertDlg - класс наследуемый от CDialog, отвечает за получение основных параметров для конвертации 3D файла в 3DO формат и саму конвертацию;

7) CGenerateDlg - класс наследуемый от CDialog, отвечает за получение основных параметров для генерации шаблона OpenGL приложения и саму генерацию.

Общая архитектура приложения на уровне основных классов представлена на рисунке 4.1.

Размещено на http://www.allbest.ru/

Рисунок 4.1 - Архитектура приложения

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

В состав спроектированного шаблона графического приложения с именем OGLApp входят следующие файлы:

1) OGLApp.h - заголовочный файл, содержащий описание класса отвечающего за начальную инициализацию и создание главного окна проекта;

2) OGLApp.cpp - содержит реализацию выше описанного класса;

3) MainFrm.h - содержит описание класса отвечающего за внешний вид главного окна проекта;

4) MainFrm.cpp - содержит реализацию выше описанного класса;

5) OGLAppDoc.h - описывает класс хранящий основные данные проекта;

6) OGLAppDoc.cpp - содержит реализацию выше описанного класса;

7) OGLAppView.h - содержит описание класса отвечающего за отображение в главном окне проекта данных из предыдущего класса;

8) OGLAppView.cpp - содержит реализацию выше описанного класса;

9) Camera.h - отвечает за описание класса предоставляющего реализацию камеры для просмотра OpenGL окна;

10) Camera.cpp - содержит реализацию выше описанного класса;

11) StdAfx.h - используется для создания пре-компилированного файла заголовка.

Основными классами шаблона являются:

1) COGLApp - главный класс приложения, наследуется от стандартного класса CWinApp. Выполняет начальную инициализацию и создание главного окна проекта;

2) СMainFrame - класс наследуемый от CFrameWnd, задает внешний вид главного окна проекта;

3) COGLAppDoc - класс наследуемый от CDocument, хранит основные данные проекта;

4) COGLAppView - класс наследуемый от CView, выполняет начальную инициализации OpenGL и отвечает за вывод данных хранящихся в предыдущем классе;

5) CCamera - класс, реализующий возможности камеры для просмотра объектов в OpenGL окне;

Общая архитектура шаблона графического приложения на уровне основных классов представлена на рисунке 4.2.

Размещено на http://www.allbest.ru/

Рисунок 4.2 - Архитектура шаблона OpenGL приложения

4.2 Информационное пространство системы

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