Домой	Поиск	Войти	Контакты		Добавить в избранное
					Сделать стартовой

ГЛАВНАЯ

ИНФОБЛОК

НОВОСТИ

ВОЙТИ

КОНТАКТЫ

БОЛЬШАЯ ЛЕНИНГРАДСКАЯ БИБЛИОТЕКА

МЕНЮ

Главная

Технология

Уголовное и уголовно-исполнительное право

Строительство и архитектура

Спорт и туризм

Социология и обществознание

Сельское лесное хозяйство и землепользование

Религия и мифология

Разное

Психология

Производство и технологии

Программирование компьютеры и кибернетика

Начертательная геометрия

Не сортированные

Оккультизм и уфология

Программирование и комп-ры

Экологическое право

Экология

Экономика

Экономико-математическое моделирование

Экономическая география

Финансовый менеджмент финансовая математика

Финансы деньги кредит

Разработка системы моделирования наблюдения за группировкой кораблей

БОЛЬШАЯ ЛЕНИНГРАДСКАЯ БИБЛИОТЕКА - РЕФЕРАТЫ - Разработка системы моделирования наблюдения за группировкой кораблей

Разработка системы моделирования наблюдения за группировкой кораблей

Факультет "Информатика и системы управления"

Кафедра "Программное обеспечение вычислительной техники и автоматизированных систем"

Курсовая работа по курсу: "Машинная графика"

Тема: "Разработка системы моделирования наблюдения за группировкой кораблей"

Москва 2007 г.

Содержание

Введение

1. Конструкторская часть
1.1 Постановка задачи
1.1.1 Обоснование выбора алгоритмов
1.1.2 Анализ алгоритмов удаления невидимых линий
1.1.3 Анализ и выбор алгоритма определения освещенности
1.1.4 Схема выбранной последовательности преобразований
1.2 Объекты сцены
1.2.1 Источник освещения
1.2.2 Прорисовываемые объекты
2. Технологическая часть
2.1 Выбор языка программирования и среды разработки
2.2 Структуры данных
2.2.1 Структура программного комплекса
2.2.2 Класс объекта
2.2.3 Интерфейсный класс
2.2.4 Структуры данных
2.2.5 Независимые процедуры
3. Использование системы
3.1 Системные требования
3.2 Работа с программой
3.2.1 Общие сведенья
3.2.2 Панель "Объекты"
3.2.3 Панель "Сцена"
3.2.4 Панель "Сцена" и выпадающее меню
3.3 Анализ результатов тестирования
Выводы
Литература

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

1. Конструкторская часть

1.1 Постановка задачи

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

Программное обеспечение должно позволять:

Загружать модели из проприетарного формата.

Моделировать построение морской группировки войск.

Моделировать движение каждой единицы группировки в отдельности в соответствие с заданной точкой назначения.

Обеспечивать квазиреалистичное изображение.

Моделировать ситуацию в квазиреальном времени.

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

Оценивать эффективности работы в условиях конкретной системы.

1.1.2 Анализ алгоритмов удаления невидимых линий
Существует множество алгоритмов удаления невидимых линий. Приведем описание нескольких из них.

Алгоритм Робертса.

Алгоритм Робертса представляет собой первый из известных алгоритмов удаления невидимых линий. Этот математически элегантный метод работает в объектном пространстве. Модификации алгоритма, использующие предварительную пространственную сортировку вдоль оси z и простые габаритные или минимаксные тесты, позволяют добиться почти линейной зависимости роста объема вычислений от роста числа объектов.

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

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

Реализация алгоритма Робертса подразделяется на следующие этапы:

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

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

Определение нелицевых граней, удаление их из списка граней и соответствующих ребер - из списка ребер.

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

Формирование списка протыканий также на основании сравнений охватывающих оболочек объектов.

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

Формирования списка возможных ребер, соединяющих точки протыкания, для пар объектов, связанных отношением протыкания.

Проверка видимости полученных ребер по отношению ко всем объектам сцены в соответствии с действиями этапов 3 и 6.

Визуализация изображения.

Алгоритм Варнока.

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

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

Кратко опишем оригинальную версию алгоритма, предложенного Варноком.

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

Возможны четыре различных случая:

Рис.1. Соотношение проекции грани с подокном

Проекция грани полностью накрывает область;

Проекция грани пересекает область, но не содержится в ней полностью;

Проекция грани целиком содержится внутри области;

Проекция грани не имеет общих внутренних точек с рассматриваемой областью.

Очевидно, что в последнем случае грань вообще никак не влияет на то, что видно в данной области.

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

Проекция ни одной грани не попадает в область.

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

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

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

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

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

При помощи изложенного алгоритма можно удалить либо невидимые линии, либо невидимые поверхности. Однако простота критерия разбиения, а также негибкость способа разбиения приводят к тому, что количество подразбиений оказывается велико. Можно повысить эффективность этого алгоритма, усложнив способ и критерий разбиения. На рис.5.17, а показан другой общий способ разбиения и дано его сравнение с изложенным ранее жестким способом, представленным на рис.2.

Рис.2. Способы разбиения окна

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

Алгоритм, использующий Z - буфер.

Впервые он был предложен Кэтмулом. Работает этот алгоритм в пространстве изображения. Идея z-буфера является простым обобщением идеи о буфере кадра. Буфер кадра используется для запоминания атрибутов (интенсивности) каждого пикселя в пространстве изображения, z-буфер - это отдельный буфер глубины, используемый для запоминания координаты Z или глубины каждого видимого пикселя в пространстве изображения. В процессе работы глубина или значение Z каждого нового пикселя, который нужно занести в буфер кадра, сравнивается с глубиной того пикселя, который уже занесен в z-буфер. Если это сравнение показывает, что новый пиксел расположен впереди пикселя, находящегося в буфере кадра, то новый пиксел заносится в этот буфер и, кроме того, производится корректировка z-буфера новым значением Z. Если же сравнение дает противоположный результат, то никаких действий не производится. По сути, алгоритм является поиском по Х и у наибольшего значения функции Z (X, у).

Более формальное описание алгоритма z-буфера таково:

Заполнить буфер кадра фоновым значением интенсивности или цвета.

Заполнить Z - буфер минимальным значением Z.

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

Для каждого Пиксель (x,y) в многоугольнике вычислить его глубину Z (x,y).

Сравнить глубину z (х, у) со значением Z-буфер (х, у), хранящимся в z-буфере в этой же позиции.

Если z (х, у) > Z-буфер (х, у), то записать атрибут этого многоугольника (интенсивность, цвет и т.п.) в буфер кадра и заменить Z-буфер (х, у) на z (х, у).

В противном случае никаких действий не производить.

Преимущества:

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

Недостатки:

Основной недостаток алгоритма - большой объем требуемой памяти.

Другой недостаток алгоритма z-буфера состоит в трудоемкости и высокой стоимости устранения лестничного эффекта, а также реализации эффектов прозрачности и просвечивания. Однако процесс сглаживание лестного эффекта в данное время переносится на уровень шейдерных микропрограмм, для обеспечения одновременной работы технологии High Dynamic Range Imaging (HDRI) и сглаживания изображения (Anti-aliasing). Поскольку алгоритм заносит пиксели в буфер кадра в произвольном порядке, то нелегко получить информацию, необходимую для методов устранения лестничного эффекта, основывающихся на предварительной фильтрации. При реализации эффектов прозрачности и просвечивания, пиксели могут заноситься в буфер кадра в некорректном порядке, что ведет к локальным ошибкам.

Обоснование выбора алгоритма.

Для реализации был выбран алгоритм Z - буфера. Он широко применяется в современных 3D движках. Алгоритм очень эффективен и практически не имеет недостатков, если реализуется аппаратно. Данный алгоритм позволяет получить представление об особенностях современных аппаратных компонентов компьютеров. Одновременно с неоценимым опытом он позволяет достичь необходимой скорости в условиях данного проекта. В дальнейшем, путем переноса некоторых вычислений с программного на аппаратный уровень можно добиться значительно увеличения производительности. Особенно с учетом особенностей современного развития компьютерных вычислений, нацеленного на перенос некоторых операций с CPU на GPU. Видеокарты от ATI серии выше Xx00 и Nvidia 8х00 позволяют реализовать данный перенос.

1.1.3 Анализ и выбор алгоритма определения освещенности
Алгоритм трассировки лучей.

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

множество проблем. Этот алгоритм может выполнять следующие действия:

Удаление невидимых поверхностей;

Перемещение;

Отражение;

Рассеяние;

Окружающее освещение;

Точечное освещение;

Наложение теней.

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

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

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

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

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

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

Краткое описание упрощенного алгоритма.

Освещение создаётся при помощи точечного источника. При рендеринге в режиме "без освещения" все объекты считаются освещёнными и теней не отбрасывают.

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

Рис. 3. Освещенность точки.

P - рассматриваемая точка

N - нормаль к поверхности

Z - вектор, ведущий от рассматриваемой точки к источнику освещения.

Обоснование выбора алгоритма.

Алгоритм трассировки лучей позволяет получить наиболее реалистичные изображения объектов сцены. Одним из свойств алгоритмов трассировки лучей заключается в большой зависимости скорости работы от разрешения экрана. Одним из главных последствий существования этой зависимости стала невозможность осуществления трассировки лучей в реальном времени на старых персональных компьютерах, оснащённых процессорами PentiumII и ниже. Эта константа даже на маленьких разрешениях - 400х300 - полностью съедала всю мощность процессора. Но сейчас этот барьер пройден. [3] Для обеспечения резкого ускорения скорости работы алгоритма необходимо использовать специальные библиотеки арифметических вычислений, оптимизированные под команды SSE. Например, уже достаточно давно доступна библиотека Small Matrix Library от компании Intel. В ней реализован класс матрица и класс вектор. По данным iXBT [3] время выполнения вычислений с учетом использования данной библиотеки на PIII 800EB выглядит следующим образом:

Операция	SSE/FPU	Время выполнения (в тактах процессора)
3x3 * 3x1	FPU	31
3x3 * 3x1	SSE	29
Transpose (3x3) * 3x1	SSE	23
4x4 * 4x1	FPU	53
4x4 * 4x1	SSE	31
Transpose (4x4) * 4x1	SSE	27
3x3 * 3x3	FPU	79
3x3 * 3x3	SSE	59
4x4 * 4x4	FPU	172
4x4 * 4x4	SSE	90
6x6 * 6x1	FPU	113
6x6 * 6x1	SSE	60
6x6 * 6x6	FPU	652
6x6 * 6x6	SSE	307
4x4 * 4x4 (general case)	SSE	529
Inverse 4x4	FPU	392
Inverse 4x4	SSE	209
Inverse 6x6	FPU	1118
Inverse 6x6	SSE	600

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

1.1.4 Схема выбранной последовательности преобразований
В результате проведения анализа алгоритмов была выбрана следующая последовательность проведения преобразований:

1.2 Объекты сцены

1.2.1 Источник освещения
В связи со спецификой требований к программному продукту, т.е. необходимости реализации естественного (Солнечного) освящения. Источник освещения сцены мы считаем точечным и удалённым от прорисовываемых объектов.

Поэтому, источник задаётся двумя углами (азимутальным и зенитным), а также цветом.

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

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

Задача нахождения пересечения треугольника и отрезка разбита на несколько этапов:

нахождение точки пересечения прямой, содержащей отрезок, и плоскости, содержащий треугольник.

проверка принадлежности найденной точки отрезку.

проверка на принадлежность этой точки треугольнику.

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

2. Технологическая часть

2.1 Выбор языка программирования и среды разработки
В качестве языка реализации программного комплекса был выбран Object Pascal, а средой разработки - Delphi 7. При данном выборе учитывались следующие моменты:

Поддержка объектно-ориентированного программирования, что облегчает создание сложных систем.

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

Обеспечение необходимой функциональности и читаемость кода программы.

Delphi был выбран оптимальной средой реализации как наиболее широко используемый и полнофункциональный компилятор на основе языка Pascal.

2.2 Структуры данных

2.2.1 Структура программного комплекса
На рисунке 2 представлена схема взаимодействия классов программы, на которой отображены основные вызовы. Стрелками с кружочком показаны включения методов в классы, а обычными стрелками - их вызовы.

Рис. 4 Структура программы

2.2.2 Класс объекта
Класс объекта хранит следующие данные о нём:

Точка "Центра объекта" - некоторая точка, перемещаемая при изменении координат объекта. Все координаты вершин вычисляются относительно этой точки.

Точка "Место назначения" - точка, необходимая для указания места назначения при движении объекта.

Цвет объекта - как и все цвета в программе задаётся в формате RGB.

Собственный угол поворота объекта.

Список треугольников, составляющих объект.

Также класс объекта предоставляет следующие методы:

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

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

Загрузка из файла. Производится чтений фигуры из файла установленного стандарта.

Поворот. Фигура поворачивается на заданные зенитные и азимутальные углы. Все повороты производятся относительно "Центра объекта".

Масштабирование. Расчет производится относительно "Центра объекта".

Поворот при перемещении. Производится расчет угла между текущим направлением объекта и направлением к точке "Место назначения". В случае необходимости происходит изменение угла с учетом заданной скорости поворота объекта.

Перемещение. Производится расчет следующего местоположения на пути к точке "Место назначения" с учетом скорости объекта. Результат присваивается точке "Центра объекта".

2.2.3 Интерфейсный класс
На уровне методов формы реализованы:

Расчет сцены. Внутри этого метода производится выбор способа расчета (с освещением, или без) в зависимости от настроек.

Очистка экрана. Очищается экран изображения и Z-буфер.

Масштабирование всех объектов с заданным коэффициентом.

2.2.4 Структуры данных
В виде глобальных переменных хранятся:

Массив объектов, включает в себя всё объекты. Динамический массив, изменяется каждый раз, когда мы создаём новый объект.

Источник освещения.

Данные о необходимом количестве просчитываемых кадров.

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

Данные о полигонах в объектах хранятся в виде односвязных списков полигонов. Каждый полигон - набор из трех вершин.

2.2.5 Независимые процедуры
Заданы следующие независимые процедуры:

Проверка видимости. Проверяет пересечение отрезка с любым объектом сцены. Применяется при учёте освещения.

Скалярное произведение векторов.

Векторное произведение векторов.

Нахождение угла между векторами.

Нахождение третьей координаты точки на треугольнике по её проекции на плоскость экрана.

Преобразование строки заданного формата ввода в треугольник.

Вычисление цвета от затенения.

Вычисление цвета от освещения.

3. Использование системы

3.1 Системные требования
программу добавлена интеллектуальная функция тестирования, которая определяет оптимальные параметры и дает рекомендации по работе с программой. Минимальная конфигурация для работы программы должна отвечать требованиям установки Windows XP.

3.2 Работа с программой

3.2.1 Общие сведенья
Интерфейс программы создавался в расчете на быстрое обучение человека, который никогда ранее не работал с подобными продуктами. Все кнопки объединены в группы элементов. Выделено 3 основные группы: Объекты, Сцена, Освещение. Каждая из групп включает в себя элементы, выполняющие возможные над объектами действия. Конечно, в соответствии с современными стандартами, добавлено выпадающее меню и интерфейс в стиле Windows XP. При выделении объекта, посредством клика на таблице, он перекрашивается в зеленый цвет.

Общий вид окна программы

3.2.2 Панель "Объекты"

Вид панели "Объекты"

При выборе объекта, посредством клика на таблице, поля координат принимают текущие значения для данного объекта, а он выделяется зеленым цветом в отображаемой сцене. Кнопки перемещения позволяют перемещать объект без ввода новых координат. Если же возникла необходимость переместить объект в заданную точку, то необходимо его выделить в таблице и, задав свойства, нажать кнопку "Применить". Если указать точку назначения ("Путь"), то после запуска циклического рендеринга кадров, объект начнет движение в заданном направлении. Кнопка "Загрузить" служит для загрузки объекта из файла. "Удалить" - удаляет выбранный в таблице объект. "-> bmp" - делает снимок экрана.

3.2.3 Панель "Сцена"

Вид панели "Сцена"

Позволяет осуществлять поворот, сдвиг сцены и настраивать масштабирование изображения. Кнопка "Рендеринг" выполняет просчет текущего изображения. "Видео" - запускает анимацию объектов в квазиреальном времени. Функция "Видео - > bmp" сделана специально для обладателей недостаточно мощных компьютеров, либо для записи и последующего отложенного воспроизведения видеороликов. Кнопка "Просмотр" позволяет просмотреть ранее записанное видео.

3.2.4 Панель "Сцена" и выпадающее меню

Вид панели "Освещение"

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

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

Процессор	Режим без теней	Итоговый результат
AMD Athlon XP 2000+ (1.6 Ghz)	Отлично	4161
P4 Northwood 2.6 GHz	Отлично	3277
AMD Athlon 64 3000+ 939 (1.8Ghz)	Отлично	5677
PIII 733Mhz	Недостаточна	1628
P4 Prescott 3.0 GHz	Отлично	2697
Core 2 Duo E4500 (2.2Ghz)	Отлично	4500
Core 2 Duo E4400@ (3.29Ghz)	Отлично	7700
AMD Turion TL-52 (1.8 Ghz)	Отлично	4100

Из сводной таблицы, что программа ощутимо быстрее выполняется на процессорах фирмы AMD. В чем же причина? В процессорах от AMD традиционно, начиная с архитектуры K7, применяется очень быстрый блок вычислений с плавающей точкой. (FPU) [4] [5] Поэтому мы видим, что Athlon XP 2000+, который вышел на рынок в 2002 работает почти на равнее с современным процессором от Intel - Core 2 Duo E4400 и в 1.5 раза обгоняет P4 3.0Ghz на ядре Prescott. Интересна разница между P4 Northwood 2.6 GHz и P4 Prescott 3.0 GHz. Известно, что в ядро Prescott могло обеспечить ускорение в операциях с плавающей запятой при сравнении с Northwood только при использовании оптимизированных под SSE3 компиляторов, что ярко и отображается на результатах. Второй вывод, который можно сделать - программа очень сильно зависит от скорости работы с памятью. Этого стоило ожидать при выборе алгоритма Z - буфера. Так AMD Athlon 64 3000+ 939 (1.8Ghz) становится вторым по скорости работы после разогнанного Core 2 Duo E4400@ (3.29Ghz). Причина - интегрированный контроллер памяти, работающий в двухканальном режиме, который позволяет значительно снизить задержки при обращении к памяти и увеличить скорость обмена данными. [4] Однако, мы видим, что Turion TL-52 достаточно сильно проигрывает настольному одночастотному коллеге. TL-52 использует память типа DDRII 633, которая обладает в два и более раза большими задержками, в сравнении с DDRI 400 и одноканальный режим работы. Однако, DDRII позволяет увеличить производительность, но при работе на достаточно больших частотах. Разгон E4400 на 62% позволил превзойти процессор с изначальной частотой на 200Mhz большей на 71%. Однако, причина такого прироста не только в росте частоты процессора. Шина процессора была разогнана на 80%, а память работает на частоте в 864Mhz. Мы видим реальный существенный рост скорости работы программы при увеличении скорости обмена данными с памятью, тогда как частота процессора влияет на результаты намного меньше.

Выводы
В работе реализованы базовые алгоритмы машинной графики: Z-буфер, трассировка лучей, алгоритм закраски флагом, взятый из курса двумерной графики. Поэтому, эта работа являет собой отчёт об усвоении курса Машинной Графики МГТУ им Н.Э. Баумана. Хотя достичь реального времени и не удалось, но примененные алгоритмы позволяют заметно ускорить выполнение программы путем перехода на использование современных программных библиотек, оптимизированных под выполнение с применением поддерживаемых наборов инструкций процессора, например SSE. В ходе проведения тестирования так же были получены и подтверждены важные знания по архитектурам современных настольных систем. Стало очевидно, почему при аппаратной реализации алгоритм Z-буфера будет выполняться намного быстрее остальных. Программа может применяться как для моделирования перемещений группировок морских кораблей, так и в учебных целях, для наглядного демонстрирования зависимости скорости выполнения расчетов от выбранных методов и архитектуры аппаратной составляющей демонстрационного стенда.

Литература
Д. Роджерс, Дж. Адамс. Математические основы машинной графики. - М: изд-во "Мир", 2001. - 277с.
С.М. Авдеева, А.В. Куров. МЕТОДИЧЕСКИЕ УКАЗАНИЯ ПО ВЫПОЛНЕНИЮ КУРСОВОЙ РАБОТЫ ПО ДИСЦИПЛИНЕ "МАШИННАЯ ГРАФИКА" Москва 1995
Сайт "iXBT" [эл. ресурс]. - режим доступа http://www.ixbt.com/video/rt-raytracing. shtml
Сайт "iXBT" [эл. ресурс]. - режим доступа http://www.ixbt.com/cpu/amd-hammer-family2. shtml
Сайт "Ф-центр" [эл. ресурс]. - режим доступа http://www.fcenter.ru/online. shtml? articles/hardware/processors/5847

	НОВОСТИ

Изменения

Прошла модернизация движка, изменение дизайна и переезд на новый более качественный сервер

	СЧЕТЧИК

БОЛЬШАЯ ЛЕНИНГРАДСКАЯ БИБЛИОТЕКА
	© 2010