Автоматизированное редактирование частиц в компьютерной графике

Введение

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

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

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

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

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

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

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

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

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

— использование графического конвейера OpenGL позволило максимально ускорить процесс расчётов, так что вывод графики в режиме реального времени возможен при очень больших количествах полигонов;

— низкие требования, стабильность и простота настройки и работы;

— удобный графический пользовательский интерфейс;

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

Отчёт состоит из шести разделов.

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

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

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

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

В разделах «Оптимизация зрительного взаимодействия оператора со средствами отображения информации па основе ЭЛТ», «Обоснование экономической целесообразности разработки ПС «Easy Particles» «представлены сведения, заданные для каждого раздела соответственно.

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

1.1 Требования к разрабатываемому программному средству Разрабатываемое программное средство должно осуществлять следующие основные функции:

— управление динамическим набором эмиттеров (систем частиц);

— управление частицами каждого эмиттера;

— управление общими параметрами рисования;

— ввод и вывод данных на внешние носители;

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

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

Входными данными приложения являются параметры эмиттеров, задаваемые пользователем, параметры режима рисования.

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

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

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

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

a) ParticleIllusion;

б) Trapcode Particular;

в) Magic Particles;

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

Trapcode Particular — встраиваемый (необязательный) модуль для пакета программ Adobe After Effects, предназначенный для редактирования частиц, разработанный компанией Trapcode. Немного менее широкий по возможностям, нежели ParticleIllusion, к тому же требующий для работы предустановленного Adobe After Effects.

Magic Particles — российский генератор частиц компании Астралакс. Позволяет быстро и наглядно создавать визуальные спецэффекты на основе систем частиц. Основное достоинство Magic Particles — мгновенное отображение всех изменений без длительного процесса визуализации. Хотя то же можно сказать и о ParticleIllusion. Аналогично, в состав Magic Particles входит около сотни готовых образцов, которые можно использовать как есть или изменять по своим потребностям. Хотя по многим аспектам функциональности данный продукт уступает ParticleIllusion, к нему постоянно выходят обновления с исправлениями и дополнениями.

Все, за исключением последнего, перечисленные редакторы частиц распространяются платно.

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

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

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

Другой важной задачей является разработка приложения с возможностями последующего расширения. Нужно отметить, что разрабатываемое в рамках дипломного проектирования программное средство является прототипом, реализующим лишь основные функциональные возможности программ данного класса. Поэтому необходимо позаботиться о будущих модификациях основной функциональности, возможностях лёгкого добавления новых параметров, а также поддержке многоплатформенности (поддержка Mac OS X). При этом очень важным остаётся вопрос разработки такого пользовательского графического интерфейса, чтобы в него можно было легко и без ущерба для удобства работы дизайнера интегрировать новые элементы, связанные с описанными выше новыми возможностями. Это очень важная задача, поэтому именно проработке графического пользовательского интерфейса следует уделить максимум времени при разработке программного средства. Более подробно о будущих планируемых расширениях редактора будет сказано ниже.

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

1.5 Описание программно-алгоритмического обеспечения решения поставленной задачи

1.5.1 Среда для проектирования и разработки программных продуктов Microsoft Visual Studio 2005

Microsoft Visual Studio — линейка продуктов компании Microsoft, включающих интегрированную среду разработки программного обеспечения и ряд других инструментальных средств. В их число входят редакторы и компиляторы языков Visual Basic.NET, Visual C++, Visual C# и некоторые другие. Также, что весьма важно, Visual Studio предлагает подробную информацию о библиотеках и языках, включённых в пакет, в MSDN — информационной библиотеке по продуктам Microsoft, с возможностью получения недостающей информации из Интернета. Любой программист, создающий приложения для Windows, весьма быстро убеждается в абсолютной необходимости данного средства при разработке. Также нужно отметить, что Microsoft Visual Studio построена в архитектуре, поддерживающей возможность использования дополнений от сторонних разработчиков, что позволяет расширять возможности среды разработки. Более подробную информацию о данном пакете можно получить на официальном сайте производителя и в Интернете.

Среда разработки MS Visual Studio 2005 была выбрана мною, так как создаваемое программное средство ориентировано для использования в ОС Windows. В ходе кодирования приложения, его тестирования и отладки и даже проектирования были использованы различные компоненты среды: компилятор C++, сборщик объектных C++ файлов, отладчик, средства обратного проектирования, позволяющие создавать диаграммы классов для проекта по исходному коду его компилируемых единиц, на основе средства MS Visio 2003.

1.5.2 Язык программирования C++

C++ — компилируемый строго типизированный язык программирования общего назначения. Поддерживает разные парадигмы программирования: процедурную, обобщённую, функциональную; наибольшее внимание уделено поддержке объектно-ориентированного программирования. В 1990;х годах язык стал одним из наиболее широко применяемых языков программирования общего назначения. Более полную информацию можно получить, например, прочитав книгу создателя языка Бьёрна Страуструпа.

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

1.5.3 wxWidgets

wxWidgets представляет собой набор библиотек для создания легко переносимых приложений для платформ Win32, Mac OS X, GTK+ и других (X11, Motif, WinCE). Он предоставляет в распоряжение разработчика единый, простой в использовании API. wxWidgets можно использовать с С++, Python, Perl, C#. В отличие от некоторых других межплатформенных средств разработки, wxWidgets позволяет создавать естественно-выглядящие на любой из перечисленных платформ приложения, так как использует собственные графические элементы платформы, вместо их эмуляции. wxWidgets — хорошо продуманный, бесплатный, расширяемый продукт с открытым исходным кодом, что делает его весьма полезным при разработке приложений. Более подробная информация доступна на официальном сайте [14], а также в прочих источниках Интернета.

Ввиду того обстоятельства, что в будущем запланировано расширение приложения в целях реализации возможности использования его под Mac OS, для разработки уже первой версии потребовалось использование межплатформенных SDK, таких как wxWidgets или Qt. Первый был выбран ввиду его простоты и доступности.

1.5.4 FreeImage

Бесплатная библиотека с открытым исходным кодом, FreeImage используется для работы с данными изображений. FreeImage предоставляет разработчику удобные средства для загрузки изображений различных форматов и унифицирует работу с ними. Это библиотека с открытым исходным кодом, поддерживающая работу с такими популярными сегодня графическими форматами, как PNG, BMP, JPEG, TIFF и другими. Для реализации отдельных аспектов (оговоренных в последующих главах) приложения возникла необходимость использования подобного рода средств. FreeImage была выбрана мною, так как библиотека довольно проста в использовании, быстра, поддерживает многопоточное использование, совместима с всеми 32-х разрядными версиями Windiws, кроме того, поддерживает межплатформенную разработку (для Linux и Mac OS X). FreeImage может использоваться с С, С++, VB, C#, Delphi, Java, а также в скриптах на Perl, Python, PHP и других. За более полной информацией можно обратиться к официальному сайту проекта.

1.5.5 TinyXML

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

1.5.6 Microsoft Office Visio 2003

Microsoft Office Visio 2003 — редактор диаграмм и блок-схем для Windows. Использует векторную графику для создания диаграмм.

Корпорация Visio была создана в 1990 г., и она довольно быстро стала известна на рынке благодаря одноименному программному продукту. По данным корпорации, в 2000 г. его применяли около четырех млн. пользователей в 60 странах мира.

Microsoft Visio 2000, сменивший предыдущую версию Visio 5.0, — первый продукт, вышедший под совместной торговой маркой Microsoft и Visio. В технологическом и организационном плане Visio Corporation стала работать в составе группы Microsoft по приложениям делового назначения.

Пользовательский интерфейс Microsoft Visio 2003 выполнен в традиционном стиле продуктов Microsoft Office.

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

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

Отметим также, что кроме файлов Visio (.vsd) можно использовать достаточно широкий спектр других файлов, в том числе графических и .html.

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

Для специалистов информационных отделов и разработчиков ПО особый интерес представляют функции пакета Microsoft Visio Professional, такие как построение схем компьютерных сетей, диаграмм баз данных, структурной схемы программ и карт Web-сайтов. При моделировании баз данных разработчик может формировать описание непосредственно в среде пакета или импортировать данные из существующих БД.

Microsoft Visio 2003 представляет большой набор средств для визуального моделирования программ — здесь можно использовать практически все распространенные типы диаграмм, описываемые с помощью Unified Modeling Language (UML) версии 1.2. При этом поддерживаются языки программирования C++, Visual Basic и Java.

После установки Microsoft Visio 2003 на компьютер в средствах разработки, в частности в Microsoft Visual Studio 2005, автоматически прописываются ссылки на пакет. С помощью команды Reverse Engineer UML Model можно автоматически сформировать описание текущего приложения, которое отображается в виде иерархического дерева в окне UML Navigator. Надо сказать, что в данном случае мы получаем детальную информацию о программе (включая описания внутренних переменных процедуры).

Это весьма краткий обзор функций Microsoft Visio 2003. Для получения более полной информации можно воспользоваться ресурсами из официального источника.

2. Проектирование и реализация задачи

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

На протяжении десятилетий теоретических исследований и практических разработок было разработано множество различных моделей жизненных циклов ПО. Можно выделить наиболее известные из них: каскадная модель, V-образная модель, модель быстрого прототипирования, модель быстрой разработки приложений (RAD), инкрементная модель. Каждая из них хорошо подходит для проектов определённого типа, однако применение её в иных случаях может привести к неудаче (большим затратам ресурсов), поэтому к выбору необходимо отнестись очень внимательно.

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

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

— полные требования не известны заранее и не постоянны;

— существует потребность в разработке достаточно сложных пользовательских интерфейсов;

— осуществляются временные демонстрации;

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

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

— системные интерфейсы усложнены;

Создание модели быстрого прототипирования было бы невозможным без работ выдающегося Фреда Брукса («The Mythical Man-Month», «No Silver Bullet, the Essence and Accidents of Programming»). Его идеи, изложенные в данных книгах, сегодня столь же актуальны, как и в 1975 году. Технологии радикально изменили мир, но многие недостатки менеджмента программных проектов по-прежнему те же. Десятки лет тому назад Брукс сказал:

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

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

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

Согласно Джону Коннэллу и Линде Шафер, эволюционным ускоренным прототипом является «легко поддающаяся модификации и расширению рабочая модель предполагаемой системы, не обязательно представляющая собой все свойства системы, благодаря которой пользователи данного приложения получают физическое представление о ключевых частях системы до ее непосредственной реализации; это — легко создаваемая, без труда поддающаяся модификации, максимально расширяемая, частично заданная рабочая модель основных аспектов предполагаемой системы» .

Таким образом, прототип — это эквивалент экспериментальной модели или «макета» в мире аппаратного обеспечения.

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

Схему метода можно изобразить следующим образом:

Рисунок 2.1 — Метод быстрого прототипирования Начало жизненного цикла разработки помещено в центре эллипса. В соответствии со схемой, базовый анализ (на основе предварительных требований) необходимых свойств и функций редактора был произведён на начальной стадии разработки (и жизненного цикла в целом). Заказчик и программист совместно определили требования и спецификации для важнейших частей системы. В результате был получен документ, описывающий в общих чертах примерные графики и результативные данные.

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

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

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

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

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

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

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

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

— благодаря меньшему объему доработок были уменьшены затраты на разработку;

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

— было обеспечено управление рисками;

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

а) очередь эмиттеров;

б) оконно-интерфейсная часть;

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

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

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

а) для эмиттера:

1) координаты в двумерной декартовой системе;

2) скорость;

3) размеры;

4) значения разброса частиц;

5) стартовая задержка и длительность генерации;

б) для частицы:

1) текстура;

2) время жизни;

3) скорость по осям;

4) гравитация по осям;

5) значения начальных и конечных растяжений;

6) значения начального и конечного цветов по каналам;

Для реализации интерфейсной части были использованы графические объекты вышеописанного межплатформенного движка wxWidgets.

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

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

Фрейм управления очередью эмиттеров представляет собой панель со схематическим отображением отдельных эмиттеров в виде пиктограмм. К функциям фрейма относятся добавление и удаление эмиттеров, копирование эмиттера со всеми его параметрами, изменение текущего эмиттера, а также порядка прорисовки эмиттеров. Для копирования и удаления эмиттеров при активном фрейме управления очередью можно использовать горячие клавиши (Ctrl+V, Ctrl+X, соответственно).

Фрейм вывода объединяет в себе всю функциональность вывода графических данных приложения. Для максимально быстрого вывода используется низкоуровневая работа с аппаратным обеспечением видеосистемы, осуществляемая посредством драйвера OpenGL. Доступ к платформенно-независимому конвейеру OpenGL осуществляется, в свою очередь, через интерфейс wxWidgets. Именно на уровне фрейма вывода осуществлено связывание оконной системы и функциональности рисования очереди эмиттеров, не зависящей от конкретного окна и работающая с буферами OpenGL. Средства wxWidgets используют для этого те или иные системные библиотеки, в зависимости от целевой платформы. Для Windows это WGL, для Mac OS X — AGL, а также стандартные Carbon (для С++) и Cocoa (Objective С).

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

Системное меню имеет следующую структуру:

— меню «Файл», отвечающее за общий сброс, сохранение и загрузку, выход из приложения;

— меню «Очередь», отвечающее за установку режима отображения эмиттеров (Playback, Loop playback, Static), добавление и удаление текущего эмиттера, копирование эмиттера и набора его параметров, сброс всех эмиттеров;

— меню «Информация», позволяющее получить информацию о способах использования редактора, а также о разработчике;

Панель инструментов содержит следующие компоненты:

а) функции установки режима отображения эмиттеров:

1) Playback;

2) Loop playback;

2) Static;

б) функции сохранения и загрузки:

1) Save;

2) Load;

в) функции настройки отображения:

1) Back color;

2) Back image;

3) режим смешивания;

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

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

2.3 Функциональная модель приложения Разработанный редактор имеет шесть базовых функциональных блоков: настройка очереди эмиттеров, обновление, отображение, ввод/вывод, настройка отображения и работа со справочной системой приложения (в базовой версии сводится к получению общей информации о функциональности редактора и разработчике, впоследствии планируется расширение).

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

Функция отображения реализует вывод на экран создаваемых эффектов.

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

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

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

2.4 Информационная модель приложения Информационная модель приложения отражает потоки информации, проходящие между его модулями и внешними сущностями.

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

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

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

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

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

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

Обобщая вышесказанное, к основным потокам данных приложения можно отнести:

а) ввод пользователем в систему параметров эмиттеров:

1) координаты в двумерной декартовой системе;

2) скорость;

3) размеры эмиттера;

4) значения разброса частиц;

5) стартовая задержка и длительность генерации;

б) ввод пользователем в систему параметров частиц эмиттера:

1) текстура;

2) время жизни;

3) скорость по осям;

4) гравитация по осям;

5) значения начальных и конечных растяжений;

6) значения начального и конечного цветов (32bit), по каналам;

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

Графически информационная модель приложения представлена в Приложении В, на диаграмме потоков данных.

2.5 Объектная модель приложения Так как приложение было разработано с использованием возможностей объектно-ориентированного языка С++, следует раскрыть его объектную структуру. Подробно объектная структура программного средства описана в Приложении Г, здесь же можно привести общий обзор системы классов.

а) класс MyApp, отвечает за инициализацию приложения, создаётся и управляется полностью из среды wxWidgets. Это корневой класс всей проектируемой части приложения.

б) модуль очереди эмиттеров. Включает в себя:

1) класс ParticleSystemChain, то есть непосредственно саму очередь; в системе существует singleton-объект данного класса;

2) содержащиеся в очереди эмиттеры — объекты класса ParticleSystem;

3) для формирования и использования корректных OpenGL текстур на основании битовых изображений используются объекты класса MyTexture.

в) класс MainFrame — корневой класс оконного пользовательского интерфейса; в системе существует singleton-объект данного класса;

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

д) объекты PSLabel применяются в PSChainFrame для представления эмиттеров, представляют собой пиктограммы;

е) PSInputFrame используется для ввода пользовательских данных активной системы;

ж) объекты классов MySpinCtrld и MySpinEditCtrld — пользовательские элементы управления, используемые для ввода чисел с плавающей точкой из указанного диапазона, применяются в PSInputFrame;

з) PSOutputFrame используется для отображения результатов работы приложения (вывода вычисленных графических примитивов — частиц); объект MyCanvas — предоставляется OpenGL в качестве контекста визуализации;

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

2.6 Требования к программным, аппаратным ресурсам и ОС Для сборки приложения необходимо наличие набора встраиваемых (статических) библиотек среды wxWidgets, установленных в системный каталог (или в один из каталогов поиска статических библиотек, указанных в настройках среды разработки Microsoft Visual Studio 2005 и в свойствах проекта). Для корректной работы приложения необходимо наличие в системе динамической библиотеки OpenGL (любой версии, по умолчанию с OS Windows поставляется версия 1.0). Драйвер OpenGL используется для растеризации графических данных, генерируемых редактором.

Приложение требует не более 30 MB оперативной памяти, 20 MB — виртуальной, 40 MB дискового пространства.

Минимальное разрешения дисплея монитора, требуемое для корректной работы приложения, составляет 1024×768 точек.

Приложение работает под управлением любой OС Windows (версии не ниже Windows XP SP2).

Кроме того, для корректной работы приложения, собранного в Microsoft Visual Studio 2005, необходимо наличие в системе установленных специальным образом библиотек (так называемых манифестов), иначе приложение не запустится. В качестве альтернативы можно собрать приложение с использованием Microsoft Visual Studio 2003, однако при этом будет использован графический пользовательский интерфейс старого образца.

3. Тестирование

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

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

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

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

— тестирование для контроля выполненных корректировок программы и данных, где подтверждалась правильность выполненной корректировки.

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

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

3.2 Тестовые примеры При тестировании был проведен ряд тестов различной направленности:

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

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

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

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

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

При устранении найденных ошибок отладка программы осуществлялась встроенным отладчиком MS Visual Studio 2005.

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

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

4. Применение программы

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

— управление динамическим набором эмиттеров (систем частиц);

— управление частицами каждого эмиттера;

— управление общими параметрами рисования;

— ввод и вывод данных на внешние носители;

4.2 Инсталляция программы Разработанное программное средство не нуждается в инсталляции. Однако следует заметить, что для работы приложения необходимо наличие в системе динамической библиотеки OpenGL любой версии (с MS Windows по умолчанию поставляется версия 1.0).

Кроме того, для корректной работы приложения, собранного в Microsoft Visual Studio 2005, необходимо наличие в системе установленных специальным образом библиотек (так называемых манифестов), иначе приложение не запустится. В качестве альтернативы можно собрать приложение с использованием Microsoft Visual Studio 2003, однако при этом будет использован графический пользовательский интерфейс старого образца. Более подробно о манифестах, их типах и назначениях, можно прочитать на официальном сайте корпорации Microsoft.

4.3 Структура входных данных Входными данными приложения служат параметры эмиттеров, задаваемые пользователем, а также параметры отображения. Более подробно со структурой входных данных можно ознакомиться в подразделе 1.1, или на диаграмме потоков данных (Приложение В).

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

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

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

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

4.5 Форма представления выходных данных Выходные данные формируются, как уже было отмечено выше, в нескольких формах. Можно просматривать выходную информацию в графическом виде непосредственно на экране редактора. Также разработчик приложения, использующий редактор (предоставляемый разработчику исходный код для вывода эффектов частиц), может выводить данные в окно своего приложения (предварительно связав его с OpenGL средствами ОС). Наконец, можно просматривать выгруженные на диск выходные данные с помощью любого текстового (XML) редактора.

5. Оптимизация зрительного взаимодействия оператора со средствами отображения информации па основе ЭЛТ

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

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

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

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

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