39305

Организация взаимодействия трехмерного редактора и визуализатора на основе трассировки лучей

Дипломная

Информатика, кибернетика и программирование

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

Русский

2013-10-02

3.93 MB

9 чел.

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

к дипломной работе

На тему: Организация взаимодействия трехмерного редактора и визуализатора на основе трассировки лучей

Студент: Болдырев Дмитрий Алексеевич

Руководитель проекта: Сапунов Григорий Владимирович

Допущен к защите        «   »             2008


Консультанты проекта:

Специальная часть  Г. В. Сапунов

Охрана труда А. Ф. Завальнюк

Зав. Кафедрой  проф. д.т.н.  В. Н. Азаров


Содержание

[1]
Содержание

[2] Аннотация

[3]
1. Введение

[4] 2. Общая часть

[4.1] 2.1. Терминология

[4.1.1] 2.1.1. Трехмерный редактор

[4.1.2] 2.1.3. Программа-визуализатор

[4.1.3] 2.1.2. Программа-модуль

[4.2] 2.2. Обзор трехмерных редакторов

[4.2.1] 2.2.1. Autodesk 3ds Max

[4.2.2] 2.2.2. NewTek Lightwave 3D

[4.2.3] 2.2.3. Autodesk Maya

[4.2.4] 2.2.4. Softimage XSI

[4.2.5] 2.2.5. Side Effects Houdini

[4.2.6] 2.2.6. Blender

[4.2.7] 2.2.7. Выбор редактора

[4.3] 2.3. Обзор файловых форматов

[4.3.1] 2.3.1. Двоичные файловые форматы

[4.3.2] 2.3.2. Текстовые файловые форматы

[4.3.3] 2.3.3. Выбор формата

[5]
3. Специальная часть

[5.1] 3.1. Схема взаимодействия визуализатора и трехмерного редактора

[5.2] 3.2. Добавление возможности чтения файлов с описанием трехмерной сцены в программу-визуализатор

[5.2.1] 3.2.1. Компиляция программы-визуализатора

[5.2.1.1] 3.2.1.1. Средства разработки

[5.2.1.2] 3.2.1.4. Настройка проекта среды разработки

[5.2.1.3] 3.2.1.5. Добавление файлов с исходным кодом

[5.2.1.4] 3.2.1.6. Настройка компилятора CUDA

[5.2.2] 3.2.2. Описание данных, передаваемых из трехмерного редактора

[5.2.3] 3.2.3. Формат файла

[5.2.4] 3.2.4. Описание разработанного класса XMLImport

[5.2.5] 3.2.5. Описание библиотеки RapidXML

[5.3] 3.3. Написание программы-модуля для трехмерного редактора

[5.3.1] 3.3.1. Архитектура программы Autodesk Maya

[5.3.1.1] 3.3.1.1. Обзор

[5.3.1.2]
3.3.1.2. Структура приложения и Dependency Graph

[5.3.2] 3.3.2. Программный интерфейс Maya API

[5.3.2.1] 3.3.2.1. Соглашение об именах

[5.3.2.2] 3.3.2.2. Класс MObject

[5.3.2.3] 3.3.2.3. Наборы функций MFn

[5.3.3] 3.3.3. Настройка среды разработки

[5.3.4] 3.3.4. Описание реализации программы-модуля

[5.4] 3.4. Анализ полученных результатов и тестирование программ

[6] 4. Охрана труда

[6.1] 4.1. Исследование возможных опасных и вредных факторов при эксплуатации ЭВМ и их влияния на пользователей

[6.1.1] 4.1.1. Введение

[6.1.2] 4.1.2. Выводы

[6.2] 4.2. Анализ влияния опасных и вредных факторов на пользователя

[6.2.1] 4.2.1. Влияние электрического тока

[6.2.2] 4.2.2. Влияние электромагнитных излучений НЧ

[6.2.3] 4.2.3. Влияние статического электричества

[6.2.4] 4.2.4. Выводы

[6.3] 4.3. Методы и средства защиты пользователей от воздействия на них опасных и вредных факторов

[6.3.1] 4.3.1. Методы и средства защиты от поражения электрическим током

[6.3.1.1] 4.3.1.1. Вывод.

[6.3.1.2] 4.3.1.2. Общие рекомендации при работе с вычислительной техникой

[6.3.1.3] 4.3.1.3. Требования к помещениям и организации рабочих мест

[6.3.1.4] 4.3.1.4. Требования к организации работы

[6.3.2] 4.3.2. Методы и средства защиты от ультрафиолетового излучения

[6.3.3] 4.3.3. Методы и средства защиты от электромагнитных полей низкой частоты.

[6.3.4] 4.3.4. Методы и средства защиты от статического электричества

[6.4] 4.4. Выводы.

[7] 5. Выводы

[8]
6. Список литературы

[9]
7. Приложение

[9.1] 7.1. Листинг с исходным кодом класса XMLImport

[9.1.1] 7.1.1. Файл XMLImport.h

[9.1.2] 7.1.1. Файл XMLImport.cpp

[9.1.3] 7.1.3. Функция InitSceneFromFile из файла main.cpp

[9.2]
7.2. Листинг с исходным кодом программы-модуля для Maya


МОСКОВСКИЙ ИНСТИТУТ ЭЛЕКТРОНИКИ И МАТЕМАТИКИ

(Технический Университет)

Кафедра

Информационно-коммуникационных технологий

 

«Утверждаю»

Зав. кафедрой

ЗАДАНИЕ

на дипломное проектирование

____________________

«___»__________20___

 

студенту

С-105

группы

дневного

отделения

(дневного, вечернего)

Болдыреву Дмитрию Алексеевичу

(фамилия, имя, отчество полностью)

I. Тема проекта

Взаимодействие трехмерного редактора и визуализатора на основе трассировки

лучей

(Утверждена приказом по институту от ________________20  ___г. №_________________)

II. Срок сдачи студентом законченного проекта

III. Техническое задание

Реализовать возможность чтения и обработки файлов с

описанием трехмерной сцены в программе-визуализаторе и разработать

программный модуль экспорта информации из трехмерного редактора

в данный тип файлов.

IV. Содержание расчетно-пояснительной записки.

А. Специальная часть проекта.

1.

Схема взаимодействия визуализатора и трехмерного редактора

2.

Добавление возможности чтения файлов с описанием трехмерной сцены в

программу-визуализатор

3.

Описание данных, передаваемых из трехмерного редактора

4.

Формат файла

5.

Написание программы-plugina для трехмерного редактора

6.

Анализ полученных результатов и тестирование программ

 

Б. Конструктивно- технологическая часть проекта.

2.

 

В. Охрана труда.

1.

Исследование возможных опасных и вредных факторов при эксплуатации ЭВМ

и их влияние на пользователей

2.

Методы и средства защиты пользователей от воздействия на них опасных и

вредных факторов.

 

Г. Экономическая часть проекта.

1.

2.

3.

4.

 Д. Решение задачи на ЭВМ.

1.

2.

3.

V. Перечень графического материала (с указанием обязательных чертежей).

1.

Схема взаимодействия визуализатора и трехмерного редактора

2.

Блок-схема алгоритма ввода информации в визуализатор

3.

Блок-схема алгоритма работы программы-plugina

4.

Вид пользовательского интерфейса трехмерного редактора

5.

Результат работы программы

6.

7.

8.

9.

10.

VI. Консультанты по проекту.

Консультант по специальной части  

(подпись)

Консультант по конструктивно-технологической части  

(подпись)

Консультант по экономической части

(подпись)

Консультант по охране труда

(подпись)

 VII. Дата выдачи задания «___»______________20____г.

Руководитель дипломного проектирования

(подпись)

Задание принял к исполнению

(подпись)

«____»____________20____г.

Примечание. 1. Задание оформляется в двух экземплярах и сдается студентом на кафедру. После утверждения один экземпляр задания выдается на руки студенту. Экземпляр задания вшивается в пояснительную записку.

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

Аннотация

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


1. Введение

В современной неинтерактивной трехмерной графике, широко использующейся, например, в кинопроизводстве, конечные изображения, как правило, рассчитываются на центральном процессоре рабочей станции. В 2007 году компания NVIDIA, один из лидеров в области разработки графических видеоадаптеров выпустила специальный компилятор CUDA, а также средства разработки для него. С помощью этого программного инструментария возможно компилировать приложения, написанные на языке «С», которые будут работать непосредственно на графических процессорах видеокарт. За последнее время мощность продвинутых моделей потребительских видеокарт выросла благодаря стремительной эволюции их архитектуры, повышения частот, на которых работают графические процессоры и графическая память, расширению полосы пропускания шины памяти и улучшения других показателей. Пиковая потенциальная производительность системы с установленной видеокартой NVIDIA GeForce 8800GTX может достигать 346 гигафлоп (в следующем поколении планируется больше 900 гигафлоп), тогда как система на основе четырехъядерного процессора Intel Core 2 Quad достигает лишь 100 гигафлоп []. Однако, в некоторых приложениях, с учетом написания эффективного кода и специфики вычислений, преимущество такой системы с видеокартой унифицированной архитектуры может достигать даже 400-кратного превосходства скорости исполнения [].

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

2. Общая часть

2.1. Терминология

2.1.1. Трехмерный редактор

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

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

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

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

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

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

[4]

2.1.3. Программа-визуализатор 

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

2.1.2. Программа-модуль

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

2.2. Обзор трехмерных редакторов

2.2.1. Autodesk 3ds Max

Один из наиболее популярных пакетов для работы с трехмерной графикой, вырос из программы 3d Studio, которая появилась в 1993 году для операционной системы DOS. Изначально разрабатывалась компанией Discreet, которая была позже куплена гигантом области CAD/CAM ПО Autodesk.

3ds Max имеет встроенный язык сценариев MaxScript, а также возможность запуска программ-модулей, написанных на языках C/C++.

Основные сферы применения продукта: компьютерные игры, телевизионная реклама, архитектурная визуализация.

Два значительных недостатка этого продукта – достаточно высокая цена и отсутствие кросс-платформенности: 3ds Max рассчитан на работу только в среде операционных систем компании Microsoft.

[7]

Рис. 1. Пользовательский интерфейс программы 3ds Max

2.2.2. NewTek Lightwave 3D

Один из первых общедоступных трехмерных редакторов промышленного масштаба. Этот пакет состоит из двух отдельных программ – «Modeling» для моделирования и «Layout» для настройки освещения, анимации и визуализации.

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

Из средств расширения функциональности доступен встроенный специально разработанный язык сценариев LScript, имеющий схожий с языком С синтаксис, и SDK для написания модулей на С/C++.

Lightwave3d в основном используется в разработке компьютерных игр, а также на телевидении и в кино (некоторые фильмы получили награду Emmy за спецэффекты). [8]

Рис. 2. Пользовательский интерфейс программы Lightwave

2.2.3. Autodesk Maya

Трехмерный редактор Maya обладает очень широкими возможностями, так как изначально был составлен из трех программ: визуализатора The Advanced Visualizer калифорнийской компании Wavefront, средства моделирования Explore французской компании Thomson Digital Image (TDI) и пакета анимации Power Animator канадской компании Alias. В конечном счете Alias приобрела TDI, а гигант сферы 3D графики SGI поглотил и Alias, и Wavefront. После этого на свет появилась Maya, работающая в среде специальной операционной системы для графической обработки Irix на графических серверах SGI, а затем была адаптирована для трех самых популярных ОС: Windows, Mac OS, Linux. Сегодня данный пакет выпускается под брендом Autodesk. 

[9]

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

Рис. 3. Пользовательский интерфейс программы Maya

Autodesk Maya обладает одним из наиболее гибких программных интерфейсов для расширения среди проприетарных программ с закрытым кодом (вследствие особый архитектуры программы, где все параметры сцены отображаются на структуре DAG  - направленном ациклическом графе) – для этого можно использовать встроенный язык сценариев Maya Embedded Language (MEL) или SDK C/C++.

2.2.4. Softimage XSI

Для того, чтобы описать пакет XSI, выделим наборы возможностей, которые можно разделить на семь основных групп: openXSI, XSI workforce, XSI performance, rendercore, mixer, XSI intuition, XSI fx.

 

Рис. 4. Пользовательский интерфейс программы XSI

openXSI: В отличие от других трехмерных редакторов, имеющих встроенные специализированные языки сценариев, для XSI можно писать сценарии на распространенных языках JScript, VBScript, Python, PerlScript, ScOps и OMScripting.

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

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

Ядром визуализации (rendercore) в XSI является mental ray, который, однако, также доступен в качестве второго визуализатора в программах 3ds Max и Maya.

С помощью mixer можно накладывать (в том числе и используя «систему слоев») различные анимации друг на друга, а также редактировать их. Хорошей возможностью является возможность проигрывания аудио – это может потребоваться, например, для осуществления синхронизации губ персонажей с их речью.

 XSI intuition позволяет изменять пользовательский интерфейс для адаптации под личные потребности.

XSI fx предназначен для базовой работы с растровой и векторной двухмерной графикой. [10]

2.2.5. Side Effects Houdini

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

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

Рис. 5. Пользовательский интерфейс программы Houdini

2.2.6. Blender

Среди рассмотренных пакетов для работы с трехмерной графикой Blender является единственным полностью бесплатным продуктом с открытым кодом. Он распространяется по лицензии GNU General Public License, наиболее популярной среди открытых решений. В связи с этим, имеет неограниченные возможности расширения и, следовательно, стремительно развивается, догоняя по функциональности закрытые коммерческие проприетарные продукты. Также стоит упомянуть и компактный установочный дистрибутив в 8 мегабайт (после установки программа занимает 25 мегабайт), что часто от нескольких десятков до сотни раз меньше других программ. [12]

Рис. 6. Пользовательский интерфейс программы Blender

2.2.7. Выбор редактора

При анализе обзора трехмерных редакторов основным критерием была популярность программы, так как она определяет количество потенциальных пользователей. После анализа выбор был сужен до двух наиболее используемых продуктов: Autodesk 3ds max и Autodesk Maya [5, 6]. Они обладают схожим набором возможностей, однако проблема 3ds max заключается в непереносимости на все операционные системы, кроме семейства ОС Windows. Поэтому, итогом этого раздела стал выбор трехмерного пакета Autodesk Maya для выполнения практической части данной дипломной работы.

2.3. Обзор файловых форматов

2.3.1. Двоичные файловые форматы 

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

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

[13]

2.3.2. Текстовые файловые форматы 

Текстовой файл – последовательность определенных печатных символов, таких как буквы, цифры, знаков пунктуации, пробелов или контрольных символов. Символы в текстовом файле принадлежат определенной кодировке (например, ASCII, ANSI или Unicode) и при правильной ее настройке в текстовом редакторе (или просмотрщике) могут быть корректно отображены. В этом и заключается основное преимущество текстового представления – чтобы просмотреть такой файл достаточно программы-просмотрщика, которая входит в состав любой операционной системы.

Текстовые файлы используются в языках разметки, с помощью которых очень удобно упорядочивать данные. Наиболее универсальный и широко используемый язык разметки – XML (Extensible Markup Language). Он полностью стандартизован, поэтому нет проблем с кодировкой (стандартом является UTF-8, с помощью которой возможно кодирование символов алфавита любого языка). В большинстве современных программ конфигурационная информация сохраняется в XML, так как с помощью этого формата возможно организовывать удобную иерархическую структуру данных. В настоящее время заметны тенденции перехода на XML, например, компания Microsoft больше 15 лет использовала двоичный формат «DOC» для своего текстового процессора Word, перешла в 2007 году на текстовой формат Office Open XML.

[14]

2.3.3. Выбор формата

В истории трехмерных редакторов большое распространение получили именно двоичные файлы (например, форматы файлов программ 3ds max, Maya), в один файл можно было сохранить сразу всю информацию о сцене, например, кроме текстового описания координат примитивов включить непосредственно двухмерные изображения, представляющие текстуры. Однако, в новые и современные программы встраивают поддержку текстовых форматов. Для примера можно привести визуализаторы Kerkythea, Indigo, а также COLLADA – продвинутый открытый XML-подобный формат, целью которого является достижение взаимодействия различных трехмерных приложений.

Вследствие того, что визуализатор не обладает пока широкими возможностями, использовать уже существующую структуру формата (например COLLADA), имеющую ненужную избыточность не имеет смысла. Для некоторых этапов тестирования практической части данной работы (проверка результатов экспорта, изменение файла при необходимости) категорически не подходит двоичный формат. Основное достоинство двоичного формата – высокая скорость обработки. Однако, работу с текстовыми файлами можно организовать так, что замедление в скорости одного полного цикла обмена данными между трехмерным редактором и визуализатором, по сравнению с использованием двоичного формата, будет несущественным (см. главу 3.2.5). В свете всего написанного, был сделан вывод, что для практической части данной дипломной работы будет разработан собственный формат хранения трехмерной сцены на основе XML и согласованный с возможностями визуализатора.


3. Специальная часть

3.1. Схема взаимодействия визуализатора и трехмерного редактора

На схеме, изображенной на рисунке 7, показана организация взаимодействия визуализатора и трехмерного редактора, используя текстовые файлы. В программе Autodesk Maya присутствует API – программный интерфейс приложения, который используется как промежуточное звено между ядром Maya и пользовательской программой-модулем. Пользовательская программа-plugin генерирует на основе внутренних данных Maya текстовой XML-файл, экспортируя тем самым информацию о трехмерной сцене (архитектура Maya API и подробности реализации программы-модуля описаны в главе 3.5, формат XML-файла в главе 3.4). Далее текстовой файл считывается визуализатором с помощью класса XMLImport, который, взаимодействуя с библиотекой XML-парсера, передает данные о трехмерной сцене через интерфейс передачи информации ядру визуализации (особенности реализации этого процесса описаны в следующей главе). Программа-визуализатор, теперь имея все необходимые данные, сможет произвести визуализацию сцены.

Рис. 7. Схема взаимодействия визуализатора и трехмерного редактора

3.2. Добавление возможности чтения файлов с описанием трехмерной сцены в программу-визуализатор

3.2.1. Компиляция программы-визуализатора

3.2.1.1. Средства разработки

Программа-визуализатор написана на языке С++. Операционная система, в которой будет компилироваться программа – Microsoft Windows XP SP2. Это связано с тем, что большинство художников/аниматоров, занимающихся трехмерной графикой используют именно ее. Средство разработки программного обеспечения – пакет Microsoft Visual Studio 2005 Service Pack 1, в состав которого входит компилятор MSVC 8.0. Также для компиляции визуализатора требуется установка инструментария для разработки приложений для графических процессоров – Nvidia CUDA 1.0 SDK, включающее в себя специальный компилятор. Тестовая компьютерная рабочая станция должна быть на основе материнской платы с поддержкой технологии PCI-Express с установленной видеокартой GeForce компании NVidia не ниже 8-ой серии.

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

Материнская плата: ASUS A8N-SLI

Процессор: AMD Athlon X2 4600+

Оперативная память: Kingston 2GB DDR PC3200

Видеокарта: Albatron GeForce 8800GTX


3.2.1.2. Установка средств разработки

 Установка средств разработки достаточно тривиальна  для пользователя среднего уровня и очень подробно описана в документациях использованных программных продуктов (а также не представляет ценности для описания данной работы), поэтому здесь описана не будет.  Следует лишь упомянуть, что инструментарий CUDA рекомендуется для удобства устанавливать в корень директории диска «C:\».

3.2.1.3. Настройка параметров переменных среды ОС

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

Данные параметры вызываются следующим образом:

Кнопка «Пуск» -> «Мой компьютер» -> (щелчок правой мышью) «Свойства» -> вкладка «Дополнительно» -> «Переменные среды».

Далее вносим значения системных переменных, в соответсвии с рисунком:

Рис. 8. Настройка параметров переменных среды ОС

3.2.1.4. Настройка проекта среды разработки

После запуска среды разработки Visual Studio, требуется создать новый проект: Visual C++ Win32 Console Application с установленным флагом «Empty Project».

В свойствах проекта нужно указать/прописать следующие значения:

  1.  Вкладка «C/C++» -> «General» -> «Additional include directories»:

«$(CUDA_INC_PATH);$(NVSDKCUDA_ROOT)/common/inc;

$(NVSDKCUDA_ROOT)/common/GLEW/include» (без кавычек)

Здесь мы указываем директории требующихся заголовочных файлов CUDA, а также файлов библиотеки OpenGL/GLUT и GLEW для обработки ввода/вывода.

  1.  Вкладка «C/C++» -> «General» -> «Debug»: Program Database (/Zi)
  2.  Вкладка «C/C++» -> «Optimization» -> «Optimization»:

Maximize Speed (/O2)

  1.  Вкладка «C/C++» -> «Preprocessor» -> « Preprocessor definitions»: WIN32;_CONSOLE
  2.  Вкладка «C/C++» ->  «Code generation» ->

«Enable minimum rebuild»: No

«Basic runtime checks»: Default

«Runtime Library»: Multi-threaded (/MT)

  1.  Вкладка «Linker» -> «General» ->  «Enable incremental linking»:

No (/INCREMENTAL:NO)

  1.  Вкладка «Linker» -> «General» ->  «Additional library directories»:

«$(CUDA_LIB_PATH);

$(NVSDKCUDA_ROOT)/common/lib;$(NVSDKCUDA_ROOT)/common/GLEW/lib» (без кавычек)

  1.  Вкладка «Linker» -> «Input» -> «Additional Dependecies»:

«cudart.lib cutil32.lib glew32.lib» (без кавычек)

  1.  Вкладка «Linker» -> «Input» -> «Optimization» -> «References»:

Eliminate Unreferenced Data (/OPT:REF)

  1.  Вкладка «Linker» -> «Input» -> «Optimization» -> «Enable COMDAT Folding»:

Do Not Remove Redundant COMDATs (/OPT:NOICF)

3.2.1.5. Добавление файлов с исходным кодом

Теперь нужно добавить исходные файлы для компиляции:

  1.  Добавляем следующие файлы с исходным кодом:

а) Заголовочные файлы (*.h):

GraphicsGems.h, LinAl.hвспомогательные операции линейной алгебры

render.hобъявление класса работы со сценой

scene.hструктуры, представляющие сцену

settings.hразличные настройки визуализации

б) Исходный код C++ (*.cpp):

main.cppглавная исполняемая программа

render.cppреализация класса работы со сценой

в) Исходный код CUDA (*.cu):

rt.cuфункции загрузки сцены

rt_kernel.cuядро визуализации

GenerateRay.cuфункции, генерирующие лучи для трассировки

  1.  Создаем фильтр “RapidXML” для удобства и добавляем туда файлы, необходимые для работы библиотеки XML-парсера:

rapidxml.hpp, rapidxml_iterators.hpp, rapidxml_print.hpp, rapidxml_utils.hpp

3.2.1.6. Настройка компилятора CUDA

Для того, чтобы произвести сборку файлов «*.cu» нужно произвести следующие действия:

  1.  В свойствах файла «GenerateRay.cu» нужно указать:

«General» -> «Tool»: Custom Build Tool

  1.  В свойствах файла «rt.cu» нужно указать:

а) «General» -> «Tool»: Custom Build Tool

б) Передать параметры коммандной строке компилятору CUDA

«Custom Build Step» -> «General» -> «Command Line»:

«$(CUDA_BIN_PATH)\nvcc.exe -ccbin "$(VCInstallDir)bin" -c -DWIN32 -D_CONSOLE -D_MBCS -Xcompiler /EHsc,/W3,/nologo,/Wp64,/O2,/Zi,/MT -I"$(CUDA_INC_PATH)" -I./ -I "$(NVSDKCUDA_ROOT)/common/inc" -I "$(NVSDKCUDA_ROOT)/common/GLEW/include" -o $(ConfigurationName)\rt.obj rt.cu» (без кавычек)

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

в) «Custom Build Step» -> «General» -> «Description»:

«Building with CUDA» (без кавычек)

Это сделано для удобства, чтобы видеть, когда работает компилятор CUDA в строке вывода отладки Output.

г) «Custom Build Step» -> «General» -> «Outputs»:

«$(ConfigurationName)\rt.obj» (без кавычек)

Здесь мы задаем имя файла объектного модуля.

д) «Custom Build Step» -> «General» -> «Additional Dependencies»:

«rt_kernel.cu» (без кавычек)

Так как файл «rt.cu» зависит от файла «rt_kernel.cu», нужно явно указать это.

  1.  Так как файл «rt_kernel.cu» собирается отдельно от среды разработки, нужно указать, что для него не требуется сборки:

«General» -> «Excluded From Build»: Yes

После всех проведенных операций можно скомпилировать и запустить программу, будет отрисована тестовая сцена, которая задана вручную. Сцена содержит в себе 7 треугольников (в данном визуализаторе треугольник является базовым примитивом). «Стены» и «пол» имеют нулевой коэффициент преломления и малый отражения – 0,01. Треугольник по центру – коэффициент преломления – 0,7, прозрачности – 1.0. Сцену освещают два точечных источника света.

Рис. 9. Результат работы визуализатора

3.2.2. Описание данных, передаваемых из трехмерного редактора

Информация, которую надо передать визуализатору – это данные о  полигон, источниках света и о камере. Полигонов в случае используемого визуализатора является треугольник, который задается тремя точками (a, b, c), каждая из которых имеет по три координаты (x, y, z), принимающие вещественные значения. В данные о каждом треугольнике отчасти также включается параметры материала – цвет (модель RGB), коэффициенты отражения, преломления и прозрачности (все три коэффициента принимают значения от 0.0 до 1.0).

Источники света задаются местоположением (одна точка), значениями цвета и интенсивностью.

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

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

3.2.3. Формат файла

Ниже приведен пример файла с описанием трехмерной сцены (три полигона, источник света, камера). Комментариями отделяются отдельные наборы сущностей, которые можно подвести под общий объект. Файл имеет кодировку UTF-8.

<scene>

<polygons>

<!-- пол -->

 <polygon>

  <color r="1.0" g="1.0" b="1.0" />

  <a x="0" y="-30" z="-150" />

  <b x="-150" y="-30" z="150" />

  <c x="150" y="-30" z="150" />

  <reflect value="0.01" />

  <refract value="0" />

  <alpha value="0" />  

 </polygon>

<!-- левая стена -->

 <polygon>

  <color r="1.0" g="0.2" b="0.2" />

  <a x="-30" y="0" z="-150" />

  <b x="-30" y="-150" z="150" />

  <c x="-30" y="150" z="150" />

  <reflect value="0.01" />

  <refract value="0" />

  <alpha value="0" />  

 </polygon>

<!-- правая стена -->

 <polygon>

  <color r="0.2" g="0.2" b="1.0" />

  <a x="30" y="0" z="-150" />

  <b x="30" y="-150" z="150" />

  <c x="30" y="150" z="150" />

  <reflect value="0.01" />

  <refract value="0" />

  <alpha value="0" />  

 </polygon>

</polygons>

<lights>

 <light>

  <position x="0" y="29" z="40" />

  <properties r="1.0" g="1.0" b="1.0" intensity="250.0" />

 </light>

</lights>

 <camera>

  <position x="0.0" y="0.0" z="0.0" />

  <up x="0.0" y="1.0" z="0.0" />

  <right x="1.0" y="0.0" z="0.0" />

  <look x="0.0" y="0.0" z="1.0" />

 </camera>

</scene>

Листинг 1. Пример XML-файла с описанием трехмерной сцены

3.2.4. Описание разработанного класса XMLImport

Класс «XMLImport» содержит конструктор, которому передается имя XML-файла с описанием трехмерной сцены – «filename». Public-функция Parse производит прохождение по всем узлам документа (который задается переменной «xmldoc», встроенного в RapidXml шаблонного типа «xml_document<>») и возвращает тип, в котором содержится информация о сцене в форме, необходимой визуализатору (TRender) . Private-функция «FileToString» обрабатывает переменную «fileString», являющейся указателем на строку и требующуюся для инициализации переменной «xmldoc».

class XMLImport

{

public:

XMLImport(const char* filename);

TRender Parse(TRender render);

private:

 char* fileString;

 void FileToString(const char* filename);

xml_document<> xmldoc;

};

Листинг 2. Объявление класса XMLImport

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

Для начала объявляем переменные указателя на шаблонный типа узла «xml_node» библиотеки RapidXml, представляющие узлы сцены и полигонов. Мы их сразу же инициализируем, обращаясь к методу «first_node» объекта документа «xmldoc», который находит корневой узел. Параметр строки в кавычках необязателен, однако очень удобен для обеспечения удобства чтения исходного текста программы. Указатель на переменную узла «params» используется для разбора параметров отдельного полигона. Так как значения параметров находятся не внутри узлов, а в их атрибутах, нам также потребуется указатель на шаблонный тип атрибутов. Тип «TPolygon» относится к интерфейсу визуализатора и является структурой, содержащей параметры полигона.

 xml_node<> *scene = xmldoc.first_node("scene");

xml_node<> *polygons = scene->first_node("polygons");

xml_node<> *params;

xml_attribute<> *attrs;

TPolygon tpolygon;

Листинг 3. Объявление и инициализация переменных типа узла

Используя те же методы класса узла, а также метод «next_sibling» (следующий узел в данной части иерархии) мы последовательно проходим все узлы типа «полигон».

 for(xml_node<> *polygon = polygons->first_node("polygon"); polygon; polygon = polygon->next_sibling("polygon"))

{ . . . }

Листинг 4. Условия цикла обхода узла полигонов

Внутри цикла мы получаем значения различных атрибутов (ниже в листинге расмотрены атрибута цвета – «r,g,b» узла «color») с помощью функции «value» и передаем их в поля структуры полигона. Функция «value» возвращает строку, поэтому требуется перевести ее в вещественное значение функцией «atof». В конце мы добавляем структуру полигона в объект  типа «TRender».

params = polygon->first_node("color");

 

attrs = params->first_attribute("r");

tpolygon.Color.R = atof(attrs->value());

attrs = attrs->next_attribute("g");

tpolygon.Color.G = atof(attrs->value());

. . .

render.AddPolygonToScene(tpolygon);

Листинг 5. Операции, производимые внутри цикла

Ниже приведена блок-схема работы класса XMLImport. Полный листинг данного класа можно посмотреть в приложении 1 (пункт 7.1).

Рис. 11. Блок-схема алгоритма ввода информации в визуализатор

3.2.5. Описание библиотеки RapidXML

RapidXml – библиотека для парсинга XML-файлов, написанная человеком по имени Marcin Kalicinski и распространяемая бесплатно и свободно по одной из двух лицензий на выбор пользователя – «Boost Software License» (Version 1.0) или «The MIT License».

 RapidXml – это попытка создать настолько быстрый XML-парсер, насколько возможно. При этом предоставляется удобство использования, соблюдается переносимость на различные платформы и минимально разумная совместимость со стандартом W3C.

 RapidXml написан на С++, его скорость близка к скорости функции «strlen()» (оценка длины строки, см. рис. 10) при сравнении с использованием одних и тех же данных. Такая высокая скорость связана со следующими особенностями его архитектуры: во-первых, парсер не копирует строки, которые обрабатывает, а содержит указатели их местоположения в XML-документе. Во-вторых, RapidXml использует собственный объект для работы с памятью, так как использование операторов new/delete снизило бы скорость работы по сравнению с этой реализацией.

[15]

Рис. 10. Сравнение производительности RapidXml с другими парсерами

3.3. Написание программы-модуля для трехмерного редактора

3.3.1. Архитектура программы Autodesk Maya

3.3.1.1. Обзор

Целостное представление системы Maya и ее декомпозиция на основные

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

Рис. 11. Система Maya

Пользователь системы Maya взаимодействует с ее графическим пользо-вательским интерфейсом. Он выбирает пункты меню, изменяет параметры, анимирует и передвигает объекты и т. д. Во время его взаимодействия с интерфейсом пользователя Maya, на самом деле, инициируется команды языка сценариев MEL. Они посылаются командному ядру (Command Engine), где интерпретируются и выполняются.

Большинство команд MEL работают с графом зависимости Dependency Graph. Это происходит потому, что на интуитивном уровне Dependency Graph можно представить как полную трехмерную сцену. Граф зависимости не только описывает то, какие данные относятся к текущей сцене, но его структура и общая схема определяют способ обработки данных. Следующая глава описывает граф зависимости.


3.3.1.2. Структура приложения и
Dependency Graph

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

Проанализировав тенденции ЗD-приложений, нетрудно обнаружить, что каждый отдельный модуль, на самом деле, можно разбить на более мелкие операции. Эти операции меньшего размера способны обрабатывать данные и передавать их следующим операциям. По сути, все функции, реализуемые обособленным модулем, можно инкапсулировать в серию взаимосвязанных операторов. Эти операторы принимают на вход одни данные и передают на выход другие. Будучи соединены последовательно, они образуют канал, или конвейер. Данные передаются первому оператору конвейера, а затем, после той или иной обработки, покидают последний оператор на другом конце. При правильном подборе операторов на одном конце конвейера можно поместить трехмерную модель, а на другом получить ряд элементов изображения. Продолжая обобщать этот подход, можно без труда прийти к тому, чтобы любые данные приходили на один конец конвейера и любые данные покидали другой конец. На самом деле, не обязательно требовать даже того, чтобы они относились к трехмерному пространству. Можно поместить на вход конвейера текстовый файл и получить на выходе отредактированную цепочку символов.

Ядро Maya, реализовано при использовании такой парадигмы потока данных. Названное ядро представлено графом зависимости- компонентом Dependency Graph. Ради простоты Dependency Graph будет обозначаться сокращенно, DG. Прежде чем двигаться дальше, должен отметить, что. с технической точки зрения, в основу DG положена двунаправленная модель, а не строгая модель потока данных.

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

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

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

Свидетельством гибкости графа DG является тот факт, что при помощи узлов создаются и обрабатываются все данные (моделирование, динамика, анимация и т. д.) в среде Maya. Этот подход к построению сложных вещей из простых строительных блоков придает Maya реальную силу и гибкость. При таком универсальном подходе нетрудно заметить, что в систему Maya, не имеющую постоянного множества интерфейсов или понятия обособленных модулей, можно с легкостью встраивать новые возможности. [16]

Рис. 12. Пример фрагмента DG

3.3.2. Программный интерфейс Maya API

3.3.2.1. Соглашение об именах

Имя каждого класса Maya начинается с заглавной буквы М, например MObject. Так как Maya не использует пространств имен C++, это помогает избегать любых конфликтов с прочими классами, описанными пользователем. Кроме того, Maya проводит разграничение между классами, помещая их в подклассы по признаку их функциональности. Хотя некоторые классы и не укладываются в типичную объектно-ориентированную иерархию «родитель – потомок», они действительно содержат общий набор функций и совместно пользуются общим префиксом. К примеру, вы обратите внимание на то, что многие классы имеют префикс МРх. От этого подкласса порождены все классы-заместители. Префиксы имен классов представлены в таблице:

Рис. 13. Таблица имен классов Maya API 

3.3.2.2. Класс MObject

Класс MObject участвует в обращении к любым данным и потому служит для доступа ко всему спектру типов данных Maya. Может показаться, что он сам фактически содержит данные, которые вы используете. В действительности он представляет собой лишь описатель другого объекта, расположенного на уровне ядра, А поскольку это только описатель, его можно считать указателем на некий внутренний элемент данных, который входит в ядро, и лишь ядро может распоряжаться этим указателем. Помимо названного указателя, объект MObject как таковой не содержит никаких данных.

Реально объект MObject содержит «пустой» указатель (void *) на некие внутренние данные, подробные сведения о которых никогда не раскрываются, так что в своем коде вам не удастся преобразовать этот указатель в нечто значащее. Только ядро Maya точно знает о том, на что ссылается указатель. Класс MObject не содержит никаких данных, а напротив, включает в себя лишь ссылку, поэтому удаляя или создавая объект класса, вы просто удаляете и создаете описатель. На деле вы не уничтожаете и не порождаете никаких внутренних данных Maya.

3.3.2.3. Наборы функций MFn

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

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

Рис. 14. Предки класса MFnTransform

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

Как Maya узнает о том, на какой тип данных ссылается объект MObject? Класс MObject содержит возвращающую тип объекта функцию-член apiTypef). Вызвав ее, каждый класс набора функций способен определить, совместим ли он с данным объектом. Кроме того, может использоваться еще одна аналогичная функция MObject с именем hasFn(). [17, 18, 19]

3.3.3. Настройка среды разработки

Для удобства настройки среды разработки стоит воспользоваться программой-мастером (wizard), которая автоматически создаст проект требуемого типа, добавит все зависимости и настройки. Ее заархивированный дистрибутив  и инструкции по установке находится в папке «MayaInstFold\Maya2008\devkit\pluginwizard\» (MayaInstFold – путь куда была установлена Maya). После ее установки в Visual Studio появится новый тип проекта «MayaPluginWizard» с иконкой-логотипом Maya:

Рис. 15. Окно с проектами Visual Studio

3.3.4. Описание реализации программы-модуля

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

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

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

Важно заметить, что система координат Maya отличается от той, которая присутствует в визуализаторе. В Maya она – правосторонняя, а в визуализаторе – левосторонняя. Поэтому, для преобразования из одной системы в другую, потребовалось умножить на «-1» все значения координат оси «z» (рис. 16).

Полный листинг программы-модуля можно посмотреть в приложении 2 (пункт 7.2).

Рис. 16. Лево- и правосторонняя системы координат

3.4. Анализ полученных результатов и тестирование программ

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

Рис. . Результат работы программы

4. Охрана труда

4.1. Исследование возможных опасных и вредных факторов при эксплуатации ЭВМ и их влияния на пользователей

4.1.1. Введение

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

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

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

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

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

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

Типовая конфигурация компьютеризированного рабочего места:

  •  ПК на основе процессора Intel Pentium III c необходимым набором устройств ввода-вывода и хранения информации (ZIP-drive, CDRW, Floppy 3.5”);
  •  лазерный принтер QMS Print System 2060 (A3);
  •  цветной XGA монитор Sony 19” (TCO 99) на базе ЭЛТ Trinitron:
  •  разрешение по горизонтали (max) - 1600 пикселей;
  •  разрешение по вертикали (max) - 1200 пикселей;
  •  легко регулируемые контрастность и яркость;
  •  частота кадровой развертки при максимальном разрешении   - 90 Гц;

частота строчной развертки при максимальном разрешении - 42 кГц;

Рассмотрим какие могут быть вредные факторы при эксплуатации указанных элементов ВТ. Питание ПЭВМ производится от сети 220В. Так как безопасным для человека напряжением является напряжение 40В, то при работе на ПЭВМ опасным фактором является поражение электрическим током.

В дисплее ПЭВМ высоковольтный блок строчной развертки и выходного строчного трансформатора вырабатывает высокое напряжение до 25кВ для второго анода электронно - лучевой трубки. А при напряжении от 5 до 300 кВ возникает рентгеновское излучение различной жесткости, которое является вредным фактором при работе с ПЭВМ (при 15 - 25 кВ возникает мягкое рентгеновское излучение).

Изображение на ЭЛТ создается благодаря кадрово-частотной развертке с частотой:

  •  85 Гц  (кадровая развертка);
  •  42 кГц (строчная развертка).

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

Во время работы компьютера дисплей создает ультрафиолетовое излучение, при  повышении плотности которого > 10 Вт/м2, оно становиться  для человека вредным фактором. Его воздействие особенно сказывается при длительной работе с компьютером.

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

4.1.2. Выводы

При эксплуатации перечисленных элементов вычислительной техники могут возникнуть следующие опасные и вредные факторы:

  •  Поражение электрическим током.
  •  Электромагнитное излучение.
  •  Ультрафиолетовое излучение.
  •  Статическое электричество.

4.2. Анализ влияния опасных и вредных факторов на пользователя

4.2.1. Влияние электрического тока

Электрический ток, воздействуя на человека, приводит к травмам:

Проходя через тело человека, электрический ток оказывает следующие воздействия:

  •  Термическое — нагрев тканей и биологической среды
  •  Электролитическое — разложение крови и плазмы
  •  Биологическое — способность тока возбуждать и раздражать живые ткани организма
  •  Механическое — возникает опасность механического травмирования в результате судорожного сокращения мышц
  •  Тяжесть поражения электрическим током зависит от:
  •  Величины тока.
  •  Времени протекания.
  •  Пути протекания.
  •  Рода и частоты тока.
  •  Сопротивления человека.
  •  Окружающей среды.
  •  Состояния человека.
  •  Пола и возраста человека. Последствия влияния электрического тока на организм человека представлены на рис  

Рисунок . Последствия влияния электрического тока на организм человека

T - длительность воздействия в милисекундах (ms)

I - величина тока в милиамперах (mA).

Общие травмы:

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

Наиболее опасным переменным током является ток 20 - 100Гц. Так как компьютер питается от сети переменного тока частотой 50Гц, то этот ток является опасным для человека.

4.2.2. Влияние электромагнитных излучений НЧ

Электромагнитные поля с частотой 60Гц и выше могут инициировать изменения в клетках животных (вплоть до нарушения синтеза ДНК). В отличие от рентгеновского излучения, электромагнитные волны обладают необычным свойством: опасность их воздействия при снижении интенсивности не уменьшается, мало того, некоторые поля действуют на клетки тела только при малых интенсивностях или на конкретных частотах. Оказывается переменное электромагнитное поле, совершающее колебания с частотой порядка 60Гц, вовлекает в аналогичные колебания молекулы любого типа, независимо от того, находятся они в мозге человека или в его теле. Результатом этого является изменение активности ферментов и клеточного иммунитета, причем сходные процессы наблюдаются в организмах при возникновении опухолей. [31]

Влияние ультрафиолетового излучения

Ультрафиолетовое излучение  электромагнитное излучение в области, которая примыкает к коротким волнам и лежит в диапазоне длин волн ~ 200 - 400 нм. [36]

  •  Различают следующие спектральные области:
  •  200 - 280 нм  бактерицидная область спектра.
  •  280 - 315 нм  Зрительная область спектра (самая вредная).
  •  315 - 400 нм  Оздоровительная область спектра.

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

  •  Серьезные повреждения глаз (катаракта).
  •  Меломанный рак кожи.
  •  Кожно-биологический эффект (гибель клеток, мутация, канцерогенные накопления).
  •  Фототоксичные реакции.

4.2.3. Влияние статического электричества

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

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

При повышении напряженности поля Е>15 кВ/м, статическое электричество может вывести из строя компьютер.

4.2.4. Выводы

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

4.3. Методы и средства защиты пользователей от воздействия на них опасных и вредных факторов

4.3.1. Методы и средства защиты от поражения электрическим током

Техническим средством защиты от поражения электрическим током является зануление. Защитное зануление - преднамеренное соединение нетоковедущих частей с нулевым защитным проводником (см. на рис. ).

Рисунок . Защитное зануление

НЗП - нулевой защитный проводник

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

Принцип защиты пользователей при занулении заключается в отключении сети за счет тока короткого замыкания, который вызывает отключение ПЭВМ от сети.

По заданным параметрам определим возможный Jк.з.

 (формула  ), где: 

Jк.з. - ток короткого замыкания [А];

Uф - фазовое напряжение [B];

rm - сопротивление катушек трансформатора [Ом];

rнзп - сопротивление нулевого защитного проводника [Ом].

Uф = 220 В

Ом

 (формула  ), где:

- удельное сопротивление материала проводника [Ом*м];

l - длина проводника [м];

s – площадь поперечного сечения проводника [мм2].

По величине  определим с каким  необходимо включить в цепь питания ПЭВМ автомат.

рмедь= 0,0175 Ом*м

=400 м ;  =150 м ;  =50 м 

; 9,1 (Ом)

(А)

, где:

K – качество автомата.

 

4.3.1.1. Вывод.

Для отключения ПЭВМ от сети в случае короткого замыкания или других неисправностей в цепь питания ПЭВМ необходимо ставить автомат с Jном = 8 А.

4.3.1.2. Общие рекомендации при работе с вычислительной техникой

Для защиты от вредных факторов имеющих место при эксплуатации ЭВМ необходимо придерживаться следующих рекомендаций:

  •  правильно организовывать рабочие места;

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

4.3.1.3. Требования к помещениям и организации рабочих мест

Особые требования к помещениям, в которых эксплуатируются компьютеры:

  •  Не допускается расположение рабочих мест в подвальных помещениях.
  •  Площадь на одно рабочее место должна быть не меньше 6 м2, а объем - не менее 20м3.

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

Рекомендуемый микроклимат в помещениях при работе с ПЭВМ:

  •  температура 19- 21°С;
  •  относительная влажность воздуха 55-62%.

В помещениях, где размещены шумные агрегаты вычислительных машин (матричные принтеры и тому подобное), уровень шума не должен превышать 75дБА, в обычных же помещениях, где стоят персональные машины, допускается максимум 65 дБА.

Помещения должны иметь естественное и искусственное освещение. Желательна ориентация оконных проемов на север или северо-восток. Оконные проемы должны иметь регулируемые жалюзи или занавеси, позволяющие полностью закрывать оконные проемы. Занавеси следует выбирать одноцветные, гармонирующие с цветом стен, выполненные из плотной ткани и шириной в два раза больше ширины оконного проема. Для дополнительного звукопоглощения занавеси следует подвешивать в складку на расстоянии 15-20 см от стены с оконными проемами.

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

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

Рабочие места должны располагаться от стен с оконными проемами на расстоянии не менее 1,5 м, от стен без оконных проемов на расстоянии не менее 1,0 м.

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

Освещенность на рабочем месте с ПЭВМ должна быть не менее:

  •  экрана - 200 лк;
  •  клавиатуры, документов и стола - 400 лк.

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

Освещенность дисплейных классов, рекомендуемая отраслевыми нормами лежит в пределах 400-700 лк и мощностью ламп до 40Вт.

В качестве источников света при искусственном освещении необходимо применять преимущественно люминесцентные лампы типа ЛБ цветовая температура (Тцв) излучения которых находится в диапазоне 3500-4200°K.

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

При установке рабочих мест нужно учитывать, что мониторы должны располагаться на расстоянии не менее 2 метров друг от друга, если брать длины от задней поверхности одного до экрана другого, и 1,2 метра между их боковыми поверхностями. При выполнении творческой работы, требующей «значительного умственного напряжения или высокой концентрации внимания», между компьютерами должны быть установлены перегородки высотой 1,5-2,0 метра.

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

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

Экран монитора должен находиться от глаз пользователя на расстоянии 600-700 мм, но не ближе 500 мм. В помещениях ежедневно должна проводиться влажная уборка.

Рабочее место должно быть оборудовано подставкой для ног, шириной не менее 300 мм, глубину не менее 400 мм, регулировку по высоте в пределах 150 мм и по углу наклона опорной поверхности до 20 градусов. Клавиатуру следует располагать на поверхности стола на расстоянии 100-300 мм от края, обращенного к пользователю, или на специальной, регулируемой по высоте рабочей поверхности.

4.3.1.4. Требования к организации работы

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

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

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

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

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

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

4.3.2. Методы и средства защиты от ультрафиолетового излучения

Энергетической характеристикой является плотность потока мощности [Вт/м2]

Биологический эффект воздействия определяется внесистемной единицей эр.

1 эр - это поток (280 - 315 нм), который соответствует потоку мощностью 1 Вт.

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

Максимальная доза облучения:

  •  7.5 мэр*ч/ м2 за рабочую смену;
  •  60 мэр*ч/м2 в сутки.

Для защиты от ультрафиолетового излучения:

  •  защитный фильтр или специальные очки (толщина стекол 2мм, насыщенных свинцом);
  •  одежда из фланели и поплина;
  •  побелка стен и потолка (ослабляет на 45-50%).

4.3.3. Методы и средства защиты от электромагнитных полей низкой частоты.

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

  •  Время работы - не более 4 часов
  •  Расстояние - не менее 50 см от источника
  •  Экранирование
  •  Расстояние между мониторами - не менее 1,5 м
  •  Не находиться  слева от монитора ближе 1.2 м, и сзади не ближе 1м.

4.3.4. Методы и средства защиты от статического электричества

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

  •  Проветривание без присутствия пользователя.
  •  Влажная уборка.
  •  Отсутствие синтетических покрытий.
  •  Нейтрализаторы статического электричества.
  •  Подвижность воздуха в помещении не более 0.2 м/с.
  •  Иметь контурное заземление.

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

4.4. Выводы.

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

5. Выводы

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

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


6. Список литературы

  1.  «PARALLEL PROCESSING WITH CUDA: Nvidia’s High-Performance Computing Platform Uses Massive Multithreading», By Tom R. Halfhill, журнал Microprocessor Report , 28.01.08, гиперссылка: http://www.nvidia.com/docs/IO/47906/220401_Reprint.pdf 
  2.  «NVIDIA Cuda: унификация графики и вычислений», Андрей Зубинский, 8 мая 2007 г, гиперссылка: http://itc.ua/node/27969
  3.  «CUDA, Supercomputing for the Masses: Part 1», Rob Farber, 2008, гиперссылка: http://www.ddj.com/hpc-high-performance-computing/207200659 
  4.  «3D графика - история, методология, инструменты», Болдырев Дмитрий, журнал кафедры ИКТ «Editory» #3-2008-3.
  5.  «3D software comparison tables», Benoît Saint-Moulin, European CG Network, гиперссылка: http://www.tdt3d.be/articles_viewer.php?art_id=99 
  6.  «Comparison of 3d tools», CGSociety Wiki, гиперссылка: http://wiki.cgsociety.org/index.php/Comparison_of_3d_tools   
  7.  «3ds Max», From Wikipedia, the free encyclopedia, гиперссылка: http://en.wikipedia.org/wiki/3ds_Max 
  8.  «LightWave 3D», From Wikipedia, the free encyclopedia, гиперссылка: http://en.wikipedia.org/wiki/LightWave 
  9.  «Maya», CGSociety Wiki, гиперссылка: http://wiki.cgsociety.org/index.php/Maya     
  10.   «XSI», CGSociety Wiki, гиперссылка: http://wiki.cgsociety.org/index.php/XSI 
  11.   «Houdini», From Wikipedia, the free encyclopedia, гиперссылка: http://en.wikipedia.org/wiki/Houdini_%28software%29 
  12.   «Blender (software)», From Wikipedia, the free encyclopedia, гиперссылка: http://en.wikipedia.org/wiki/Blender_%28software%29 
  13.   «Binary file», From Wikipedia, the free encyclopedia, гиперссылка: http://en.wikipedia.org/wiki/Binary_file 
  14.   «Text file», From Wikipedia, the free encyclopedia, гиперссылка: http://en.wikipedia.org/wiki/Text_file 
  15.   «RapidXml Manual version 1.1», Marcin Kalicinski, 2007, гиперссылка: http://rapidxml.sourceforge.net/manual.html
  16.   «COMPLETE MAYA PROGRAMMING. An Extensive Guide to MEL and the C++API», David A. D. Gould, Academic Press - MORGAN KAUFMANN PUBLISHERS, 2002
  17.   «gpExport - a Maya Exporter», Florian Loitsch, 2004, гиперссылка:

http://florian.loitsch.com/gpExport/ 

  1.  «How to Write a Simple Maya Model Exporter». Rafael Baptista, gamedev.net, 18.04.2003, гиперссылка: http://www.gamedev.net/reference/articles/article1906.asp 
  2.  «The Maya Exporter Factfile», Robert Bateman, 2004, гиперссылка:

http://www.robthebloke.org/research/index.htm 


7. Приложение

7.1. Листинг с исходным кодом класса XMLImport

7.1.1. Файл XMLImport.h

#ifndef XMLIMPORT_H

#define XMLIMPORT_H

#include "RapidXML\rapidxml.hpp"

#include <iostream>

#include <string>

#include <fstream>

#include "render.h"

using namespace rapidxml;

using namespace std;  

class XMLImport

{

public:

XMLImport(const char* filename);

TRender Parse(TRender render);

private:

 char* fileString;

 void FileToString(const char* filename);

xml_document<> xmldoc;

};

#endif //XMLIMPORT_H

7.1.1. Файл XMLImport.cpp

#include "XMLImport.h"

#include "scene.h"

using namespace rapidxml;

using namespace std;

XMLImport::XMLImport(const char* filename)

{

FileToString(filename);

xmldoc.parse<0>(fileString);

}

void XMLImport::FileToString(const char* filename)

{

FILE* file = fopen(filename, "rb");

 if (!file) {cout << "File " << filename << " does not exist\n"; return;}

fseek(file, 0, SEEK_END);

 long length = ftell(file);

fseek(file, 0, SEEK_SET);

 if (length < 0)

{

 cout << "File " << filename << " is empty\n";

 fclose(file);

 return ;

}

 

 try

{

 fileString = new char[length + 1];

 if (!fileString) {cout << "Parsing string is null\n";return;}

}

 catch (const std::bad_alloc&)

{

 cout << "Parsing string: allocation error\n";

 fclose(file);

 return;

}

size_t read = fread(fileString, (size_t)length, 1, file);

fclose(file);

 if (read != 1)  

{

cout << "Parsing string: reading error\n";

 delete[] fileString;

 return;

}

fileString[length] = 0;

 //cout << fileString << endl;

}

TRender XMLImport::Parse (TRender render)

{

xml_node<> *scene = xmldoc.first_node("scene");

xml_node<> *polygons = scene->first_node("polygons");

 

xml_node<> *lights = polygons->next_sibling("lights");

xml_node<> *camera = lights->next_sibling("camera");

 

xml_node<> *params;

xml_attribute<> *attrs;

TPolygon tpolygon;

 

TLightSource tlight;

cout << "Parsing scene..." << endl;

cout << "Parsing polygons..." << endl;

 for(xml_node<> *polygon = polygons->first_node("polygon"); polygon; polygon = polygon->next_sibling("polygon"))

{

 params = polygon->first_node("color");

 

 attrs = params->first_attribute("r");

 tpolygon.Color.R = atof(attrs->value());

 /*cout << tpolygon.Color.R << endl;*/

 attrs = attrs->next_attribute("g");

 tpolygon.Color.G = atof(attrs->value());

 /*cout << tpolygon.Color.G << endl;*/

 attrs = attrs->next_attribute("b");

 tpolygon.Color.B = atof(attrs->value());

 /*cout << tpolygon.Color.R << endl;*/

 params = params->next_sibling("a");

 

 attrs = params->first_attribute("x");

 tpolygon.A.x = atof(attrs->value());

 /*cout << tpolygon.A.x << endl;*/

 attrs = attrs->next_attribute("y");

 tpolygon.A.y = atof(attrs->value());

 /*cout << tpolygon.A.y << endl;*/

 attrs = attrs->next_attribute("z");

 tpolygon.A.z = atof(attrs->value());

 /*cout << tpolygon.A.z << endl;*/

 params = params->next_sibling("b");

 attrs = params->first_attribute("x");

 tpolygon.B.x = atof(attrs->value());

 /*cout << tpolygon.B.x << endl;*/

 attrs = attrs->next_attribute("y");

 tpolygon.B.y = atof(attrs->value());

 /*cout << tpolygon.B.y << endl;*/

 attrs = attrs->next_attribute("z");

 tpolygon.B.z = atof(attrs->value());

 /*cout << tpolygon.B.z << endl;*/

 params = params->next_sibling("c");

 attrs = params->first_attribute("x");

 tpolygon.C.x = atof(attrs->value());

 /*cout << tpolygon.C.x << endl;*/

 attrs = attrs->next_attribute("y");

 tpolygon.C.y = atof(attrs->value());

 /*cout << tpolygon.C.y << endl;*/

 attrs = attrs->next_attribute("z");

 tpolygon.C.z = atof(attrs->value());

 /*cout << tpolygon.C.z << endl;*/

 params = params->next_sibling("reflect");

 attrs = params->first_attribute("value");

 tpolygon.KReflection = atof(attrs->value());

 //cout << tpolygon.KReflection << endl;

 params = params->next_sibling("refract");

 attrs = params->first_attribute("value");

 tpolygon.KRefraction = atof(attrs->value());

 /*cout << tpolygon.KRefraction << endl;*/

 params = params->next_sibling("alpha");

 attrs = params->first_attribute("value");

 tpolygon.Alpha = atof(attrs->value());

 /*cout << tpolygon.Alpha << endl;*/

 render.AddPolygonToScene(tpolygon);

}

cout << "Parsing lights..." << endl;

 for(xml_node<> *light = lights->first_node("light"); light; light = light->next_sibling("light"))

{

 params = light->first_node("position");

 attrs = params->first_attribute("x");

 tlight.Position.x  = atof(attrs->value());

 /*cout << tlight.Position.x << endl;*/

 attrs = attrs->next_attribute("y");

 tlight.Position.y = atof(attrs->value());

 /*cout << tlight.Position.y << endl;*/

 attrs = attrs->next_attribute("z");

 tlight.Position.z = atof(attrs->value());

 /*cout << tlight.Position.z << endl;*/

 

 params = params->next_sibling("properties");

 attrs = params->first_attribute("r");

 float r = atof(attrs->value());

 /*cout << attrs->value() << endl;*/

 attrs = attrs->next_attribute("g");

 float g = atof(attrs->value());

 /*cout << attrs->value() << endl;*/

 attrs = attrs->next_attribute("b");

 float b = atof(attrs->value());

 /*cout << attrs->value() << endl;*/

 attrs = attrs->next_attribute("intensity");

 float i = atof(attrs->value());

 /*cout << attrs->value() << endl;*/

 tlight.Light.Init(r, g, b, i);

 render.AddLightSourceToScene(tlight);

}

 cout << "Parsing camera..." << endl;

 params = camera->first_node("position");

 

 attrs = params->first_attribute("x");

 float x = atof(attrs->value());

 /*cout << attrs->value() << endl;*/

 attrs = attrs->next_attribute("y");

 float y = atof(attrs->value());

 /*cout << attrs->value() << endl;*/

 attrs = attrs->next_attribute("z");

 float z = atof(attrs->value());

 /*cout << attrs->value() << endl;*/

 render.GetScene()->Camera.Position = make_float3(x, y, z);

   

 params = params->next_sibling("up");

 

 attrs = params->first_attribute("x");

 x = atof(attrs->value());

 /*cout << attrs->value() << endl;*/

 attrs = attrs->next_attribute("y");

 y = atof(attrs->value());

 /*cout << attrs->value() << endl;*/

 attrs = attrs->next_attribute("z");

 z = atof(attrs->value());

 /*cout << attrs->value() << endl;*/

 render.GetScene()->Camera.Up = make_float3(x, y, z);

 params = params->next_sibling("right");

 

 attrs = params->first_attribute("x");

 x = atof(attrs->value());

 /*cout << attrs->value() << endl;*/

 attrs = attrs->next_attribute("y");

 y = atof(attrs->value());

 /*cout << attrs->value() << endl;*/

 attrs = attrs->next_attribute("z");

 z = atof(attrs->value());

 /*cout << attrs->value() << endl;*/

 render.GetScene()->Camera.Right = make_float3(x, y, z);

 params = params->next_sibling("look");

 

 attrs = params->first_attribute("x");

 x = atof(attrs->value());

 /*cout << attrs->value() << endl;*/

 attrs = attrs->next_attribute("y");

 y = atof(attrs->value());

 /*cout << attrs->value() << endl;*/

 attrs = attrs->next_attribute("z");

 z = atof(attrs->value());

 /*cout << attrs->value() << endl;*/

 render.GetScene()->Camera.Look = make_float3(x, y, z);

 cout << "Parsing scene done." << endl;

 return render;

}

7.1.3. Функция InitSceneFromFile из файла main.cpp

void InitSceneFromFile()

{

 

 

 char* xmlFileName = "scene.xml";

XMLImport import(xmlFileName);

 

render = import.Parse(render);

}


7.2. Листинг с исходным кодом программы-модуля для Maya

#include <maya/MSimple.h>

#include <maya/MSimple.h>

#include <maya/MGlobal.h>

#include <maya/MDagPath.h>

#include <maya/MDagPathArray.h>

#include <maya/MIntArray.h>

#include <maya/MPointArray.h>

#include <maya/MVectorArray.h>

#include <maya/MObjectArray.h>

#include <maya/MPoint.h>

#include <maya/MVector.h>

#include <maya/MMatrix.h>

#include <maya/MAngle.h>

#include <maya/MSelectionList.h>

#include <maya/MPlugArray.h>

#include <maya/MItDag.h>

#include <maya/MItDependencyNodes.h>

#include <maya/MItMeshPolygon.h>

#include <maya/MFnMesh.h>

#include <maya/MFnCamera.h>

#include <maya/MFnDependencyNode.h>

#include <maya/MFnLambertShader.h>

#include <maya/MFnPhongShader.h>

#include <maya/MFnAreaLight.h>

#include <maya/MFnDirectionalLight.h>

#include <maya/MFnAmbientLight.h>

#include <maya/MFnLight.h>

#include <maya/MFnPointLight.h>

#include <maya/MFnSpotLight.h>

#include <maya/MFnTransform.h>

#include <iostream>

#include <fstream>

#include <set>

#include <vector>

#include <string>

#include <cassert>

bool isObjectVisible(const MDagPath& path) {

   MStatus status;

   MFnDagNode node(path);

   MPlug vPlug = node.findPlug("visibility", &status);

   bool visible = true;

   if (status == MS::kSuccess)

       vPlug.getValue(visible);

   status.clear();

   MPlug iPlug = node.findPlug("intermediateObject", &status);

   bool intermediate = false;

   if (status == MS::kSuccess)

       iPlug.getValue(intermediate);

   return visible && !intermediate;

}

bool areObjectAndParentsVisible(const MDagPath& path) {

   bool result = true;

   MDagPath searchPath(path);

   for (;;) {

       if (!isObjectVisible(searchPath)) {

           result = false;

           break;

       }

       if (searchPath.length() <= 1)

           break;

       searchPath.pop();

   }

   return result;

}

bool isCameraRenderable(const MDagPath& path) {

   MStatus status;

   MFnDagNode node(path);

   MPlug rPlug = node.findPlug("renderable", &status);

   bool renderable = true;

   if (status == MS::kSuccess)

       rPlug.getValue(renderable);

   return renderable;

}

MMatrix BuildTransform(const MObject& obj)

{

MFnTransform fn(obj);

MMatrix M = fn.transformationMatrix();

 if (fn.parentCount()>0) {

 return M* BuildTransform(fn.parent(0)) ;

}

 return M;

}

bool getShaderFromEngine(const MObject& obj, MFnDependencyNode& node) {

   if (!obj.hasFn(MFn::kShadingEngine))

       return false;

   MFnDependencyNode seNode(obj);

   MPlug shaderPlug = seNode.findPlug("surfaceShader");

   if (shaderPlug.isNull())

       return false;

   MPlugArray plugs;

   shaderPlug.connectedTo(plugs, true, false);

   for (unsigned int i = 0; i < plugs.length(); i++) {

       MObject sObj = plugs[i].node();

       

       if (sObj.hasFn(MFn::kLambert)) {

           node.setObject(sObj);

           return true;

       }

   }

   return false;

}

void exportMeshAndPhong(const MDagPath& path, std::ofstream& file) {

 bool instancing = path.isInstanced();

   if (instancing) {

       if (path.instanceNumber() != 0)

           return;

       else {

           MDagPathArray paths;

           path.getAllPathsTo(path.node(), paths);

           bool hasVisible = false;

           for (unsigned int i = 0; i < paths.length() && !hasVisible; i++)

               hasVisible |= areObjectAndParentsVisible(paths[i]);

           if (!hasVisible)

               return;

       }

   } else if (!areObjectAndParentsVisible(path))

       return;

   MFnMesh mesh(path);

   int numPoints = mesh.numVertices();

   int numTriangles = 0;

   for (MItMeshPolygon it(path); !it.isDone(); it.next()) {

       int tri;

       it.numTriangles(tri);

       numTriangles += tri;

   }

   if (numPoints == 0 || numTriangles == 0) return;

file << "\n<!-- Mesh: " << path.fullPathName().asChar()

  << ", Triangles: " << numTriangles << " -->" << std::endl;

  

MColor color;

MColor trans;

   float refl = 0;

 float refr = 0;

   MObjectArray shaders;

   MIntArray polyShaderIndices;

   mesh.getConnectedShaders(path.instanceNumber(), shaders, polyShaderIndices);

   MObject engine = shaders[0];

   MFnDependencyNode shader;

   if (getShaderFromEngine(engine, shader))

 if (shader.object().hasFn(MFn::kPhong))

 {

           MFnPhongShader shader(shader.object());

           color = shader.color();

  trans = shader.transparency();

  refl = shader.reflectivity();

  if(shader.rtRefractedColor())

  refr = shader.refractiveIndex();

  if(refr > 1) refr = 1.0;

       }

   unsigned int t = 0;

   MPointArray triVertCoords;

   MIntArray triangleVertices;

   MIntArray polygonVertices;

   std::vector<int> faceMaterials(numTriangles);

   for (MItMeshPolygon mItMeshPolygon(path); !mItMeshPolygon.isDone(); mItMeshPolygon.next()) {

       mItMeshPolygon.getVertices(polygonVertices);

       int numVerts = (int) polygonVertices.length();

       int numTriangles; mItMeshPolygon.numTriangles(numTriangles);

 while (numTriangles--) {

           mItMeshPolygon.getTriangle(numTriangles, triVertCoords, triangleVertices, MSpace::kWorld);          

  MPoint a = triVertCoords[0];

  MPoint b = triVertCoords[1];

  MPoint c = triVertCoords[2];

  file << "\t<polygon>" << "\n";

  

  file << "\t\t<color r=\"" << color.r

     << "\" g=\"" << color.g

     << "\" b=\"" << color.b

        << "\" />" << "\n";

  

  file << "\t\t<a x=\"" << a.x

       << "\" y=\"" << a.y

    << "\" z=\"" << -a.z

    << "\" />" << "\n";

  file << "\t\t<b x=\"" << b.x

    << "\" y=\"" << b.y

    << "\" z=\"" << -b.z

    << "\" />" << "\n";

  file << "\t\t<c x=\"" << c.x

    << "\" y=\"" << c.y

    << "\" z=\"" << -c.z

    << "\" />" << "\n";

  

  file << "\t\t<reflect value=\"" << refl

        << "\" />" << "\n";

  

  file << "\t\t<refract value=\"" << refr

       << "\" />" << "\n";

  file << "\t\t<alpha value=\"" << trans.r

       << "\" />" << "\n";

 

  file << "\t</polygon>" << "\n";

 }

}

   

}

void exportCamera(const MDagPath& path, std::ofstream& file) {

   MFnCamera camera(path);

   if (!isCameraRenderable(path)) return;

   MSpace::Space space = MSpace::kWorld;

   MPoint pos = camera.eyePoint(space);

MVector look = camera.viewDirection(space);

MVector up = camera.upDirection(space);

MVector right = camera.rightDirection(space);

 

 

std::cout << "Exporting camera: " << path.fullPathName().asChar() << " ..." << std::endl;

   file << "<camera>" << std::endl;

   file << "\t<position x=\"" << pos.x << "\" y=\"" << pos.y << "\" z=\"" << -pos.z << "\"/>" << std::endl;

   file << "\t<up x=\"" << up.x << "\" y=\"" << up.y << "\" z=\"" << -up.z << "\"/>" << std::endl;

file << "\t<right x=\"" << right.x << "\" y=\"" << right.y << "\" z=\"" << -right.z << "\"/>" << std::endl;

   file << "\t<look x=\"" << look.x << "\" y=\"" << look.y << "\" z=\"" << -look.z << "\"/>" << std::endl;

file << "</camera>" << std::endl;

   file << std::endl;

}

void OutputLight(std::ofstream& ofs,MObject &obj)

{

assert( !obj.isNull() );

assert( obj.hasFn(MFn::kLight) );

MFnLight fnLight(obj);

 if ( !fnLight.isIntermediateObject() )

{

 

 MColor color(0.0f,0.0f,0.0f);

 color = fnLight.color();

 MVector p(0,0,0);

 MFnTransform fnXform( fnLight.parent(0) );

 MMatrix ws = BuildTransform(fnXform.object());

 ofs << "\t<light>" << "\n"

  << "\t\t<position x=\"" << ws(3,0) << "\""

  <<   " y=\"" << ws(3,1) << "\""

  <<          " z=\"" << -ws(3,2) << "\""

            << "/>\n"

  

  << "\t\t<properties r=\"" << color.r << "\""

  <<     " g=\"" << color.g  << "\""

  <<            " b=\"" << color.b  << "\""

  <<    " intensity=\"" << fnLight.intensity()*25.5 << "\""

      << "/>\n"

  << "\t</light>"

  << std::endl;

}

}

DeclareSimpleCommand( GPURTExport, "GIiRT Team", "2008");

MStatus GPURTExport::doIt(const MArgList& args) {

MString filename = ".\\plug-ins\\scene.xml";

std::cout << "Exporting scene to: " << filename.asChar() << " ..." <<std::endl;

   std::ofstream file(filename.asChar());

   MStatus status;

file << "<scene>" << std::endl << std::endl;

file << "<polygons>" << std::endl;

   for (MItDag mItDag = MItDag(MItDag::kBreadthFirst); !mItDag.isDone(&status); mItDag.next())

{

       MDagPath path;

       status = mItDag.getPath(path);

       if (path.apiType(&status) == MFn::kMesh)

 {

std::cout << "Exporting mesh: " << path.fullPathName().asChar() << " ..." << std::endl;

           exportMeshAndPhong(path, file);    

       }

   }

file << "</polygons>" << std::endl;

MItDependencyNodes itDep(MFn::kInvalid);

file << "<lights>" << std::endl;

 while (!itDep.isDone())

{

  

 MObject item = itDep.item();

 switch(item.apiType())

 {

     case MFn::kLight:

  case MFn::kAreaLight:

  case MFn::kAmbientLight:

  case MFn::kDirectionalLight:

  case MFn::kPointLight:

  case MFn::kSpotLight:

  std::cout << "Exporting light..." << std::endl;

  OutputLight(file,item);

  break;

  default:

  break;

 }

 itDep.next();

}

 

file << "</lights>" << std::endl;

 

 for (MItDag mItDag = MItDag(MItDag::kBreadthFirst); !mItDag.isDone(&status); mItDag.next())

{

    MDagPath path;

 status = mItDag.getPath(path);

 if (path.apiType(&status) == MFn::kCamera)

 {

       exportCamera(path, file);

 }

   }

file << "</scene>" << std::endl;

 

file.close();

   std::cout << "Exporting scene done." << std::endl;

   return MS::kSuccess;

}

Москва 2008 г.


 

А также другие работы, которые могут Вас заинтересовать

43057. Разработка предложений по созданию логистической системы 319.93 KB
  Выбор и обоснование типа автотранспортного средства.1 Поставщики № поставщика Поставщик 51 Полтава 54 Карловка полтавса 61 Донецк 67 Красноармейск донец 83 ВолодарскВолынский житомир 85 Черняхов житомир 87 Городница житомио 114 Городище луганс 200 Монастыриска тернопол 350 Курджиново краснодар Порты отправления: Ейск Херсон Керчь. т Стоимость транспортировки 1т за 1км: С1км = 05 ден. Общая характеристика проектной ситуации Транспортная характеристика груза Стекло в ящиках витринное: Твердый прозрачный хрупкий материал получаемый...
43058. Разработка информационной системы по учёту продукции сети аптек 1001.5 KB
  Результаты дипломной работы – программное средство, с помощью которого можно вести учет продукции, оно является Windows – приложением и имеет удобный интерфейс. Программное средство даёт возможность просматривать данные, добавлять новые данные, изменять и удалять существующие данные, а также осуществлять поиск по таблицам.
43059. Проект электродинамического громкоговорителя 601 KB
  Для этого по графику зависимости (xm) (рис.2) находим минимальное допустимое, при заданной амплитуде смещения xm, значение ширины свободного воздушного зазора bз, от размера которого зависит скорость теплообмена и допустимая удельная мощность, которая рассеивается единицей поверхности. Величину Руд находим по графику зависимости Руд() (рис.3).
43060. МЕНЕДЖМЕНТ ПРОФЕСІЙНОЇ ДІЯЛЬНОСТІ 197.5 KB
  5 Методичні вказівки з виконання курсової роботи в межах курсу Менеджмент професійної діяльності для студентів спеціальностей напрямку підготовки 8. В процесі виконання курсової роботи керівником проектування здійснюються індивідуальні і групові консультації. Методичні вказівки З виконаннЯ курсової роботи 4.
43061. Основи менеджменту. Методичні вказівки 263 KB
  У роботі передбачається що студент уважно розгляне зовнішні і внутрішні чинники що впливають на діяльність організації і з урахуванням особливостей моменту буде використовувати розглянуті теоретичні положення. Загальний аналіз діяльності конкретної організації. Опис організації і її продукту. Бачення майбутнього організації.
43062. Модернизация привода главного движения универсального токарно-винторезного станка модели 1М63 2.8 MB
  Станок универсальный токарно-винторезный модели 1М63 предназначен для выполнения самых разнообразных токарных работ, в том числе точения конусов и нарезания резьб метрической, дюймовой, модульной и питчевой.
43063. Расчет аппарата гашения извести в производстве известкового молока на ОАО «АВИСМА» 319 KB
  Гашение извести протекает по реакции: CO H2O = COH2 1593 ккал. Вместе с тем следует избегать и переохлаждения гасящейся извести так как оно может значительно замедлить процесс гашения извести. С ростом температуры выделившийся гидрат окиси кальция выпадает в осадок и обволакивает поверхность кусков негашеной извести.
43064. Детали машин, расчет основных показателей 1.52 MB
  Выбор электродвигателя и кинематический расчет привода. Расчет клиноременной передачи. Расчет двухступенчатого цилиндрического редуктора. Предварительный расчет валов. Конструктивные размеры корпуса редуктора Определение реакций в подшипниках...
43065. Социальные изменения. Понятие социального прогресса и модернизации 17 KB
  Понятием «социальные изменения» обозначаются различные перемены, происходящие в течение некоторого времени внутри социальных систем и во взаимоотношениях между ними, в обществе в целом как социальной системе.