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

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

Цель описываемой работы - создать систему отрисовки 3D сцен с возможностью динамичнского освещения в реальном времени. Такую систему в среде разработки видеоигр (для которых, обычно, предназначаются такие продукты в первую очередь) принято называть «графическим движком» (graphic engine). Графический движок - является основной частью сложного комплекса для разработки игрового приложения, называемого «игровым движком».

Игровой движок (англ. game engine) - это центральный программный компонент компьютерных и видеоигр и других интерактивных приложений с графикой, обрабатываемой в реальном времени. Он обеспечивает основные технологии, упрощает разработку и часто дает игре возможность запускаться на нескольких платформах, таких как игровые консоли и настольные операционные системы, например, GNU/Linux, Mac OS X и Microsoft Windows.

Словосочетание «игровой движок» подразумевает целый комплекс прикладных программ, включающий графический движок для 2D или 3D графики, физический движок, звук, набор инструментария, анимацию, искусственный интеллект, сетевой код, управление памятью и так далее. Строго говоря, все части кода, написанные программистами при разработке игры, являются компонентами движка. Игровой процесс (gameplay) определяется функциями, реализованными в этих программах.

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

Как и другие ППО решения, игровые движки обычно платформо-независимы и позволяют некоторой игре запускаться на различных платформах, включая игровые консоли и персональные компьютеры, с некоторыми внесенными в исходный код изменениями (или вообще без таковых). Часто игровое ППО имеет компонентную архитектуру, позволяющую заменять или расширять некоторые системы движка более специализированными (и часто более дорогими) ППО компонентами, например, Havok - для физики, FMOD - для звука или SPEEDTREE - для рендеринга. Некоторые игровые движки, такие как RENDERWARE, проектируются как набор слабосвязанных ППО компонентов, которые могут выборочно комбинироваться для создания собственного движка, вместо более традиционного подхода расширения или настройки гибкого интегрируемого решения. Тем не менее расширяемость достигнута и остается высокоприоритетной в игровых движках изза широких возможностей их применения. Несмотря на специфичность названия, игровые движки часто используются в других типах интерактивных приложений, требующих графику в реальном времени, таких как рекламные ролики, архитектурные визуализации, обучающие симуляторы и среды моделирования.

Некоторые игровые движки предоставляют только возможности 3D рендеринга в реальном времени вместо всей функциональности, необходимой играм. Эти движки доверяют разработчику игры реализацию остальной функциональности или ее сбор на основе других игровых ППО компонентов. Такие типы движков обычно относят к «графическим движкам», «движкам рендеринга» или «3D движкам» вместо более содержательного термина «игровой движок». Однако эта терминология используется противоречиво: так, многие полнофункциональные игровые 3D движки упомянуты просто как «3D движки». Некоторые примеры графических движков: REALMFORGE, Ogre 3D, Power Render, Crystal Space и Genesis3D.

Графический движок (англ. graphics engine; иногда «рендерер» или «визуализатор») - подпрограммное обеспечение, основной задачей которого является визуализация (рендеринг) двухмерной или трехмерной компьютерной графики. Может существовать как отдельный продукт или в составе игрового движка. Может использоваться для визуализации отдельных изображений или компьютерного видео. Графические движки, использующееся в программах по работе с компьютерной графикой (таких, как 3ds Max, Maya, Cinema 4D, Zbrush, Blender), обычно называются «рендерерами», «отрисовщиками» или «визуализаторами». Само название «графический движок» используется, как правило, в компьютерных играх.

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

На этапе становления компьютерных игр графический движок являлся главнейшей частью игрового движка. Собственно, примерно 90-95% игрового движка составлял именно графический движок (остальную часть занимали подсистемы ввода / вывода и т.п.). Однако с середины 90-х годов вследствие стремительного развития компьютерных игр разработчики игр начали добавлять в свои продукты и другие подсистемы, такие как звуковой движок, работа с сетью.

Чаще всего 3D движки или системы рендеринга в игровых движках построены на графическом API, таком как Direct3D или OPENGL, который обеспечивает программную абстракцию GPU или видеокарты. Низкоуровневые библиотеки, например, DIRECTX, SDL и OPENAL, также используются в играх, так как обеспечивают аппаратно-независимый доступ к другому аппаратному обеспечению компьютера, такому как устройства ввода (мышь, клавиатура и джойстик), сетевые и звуковые карты. До появления аппаратно-ускоряемой 3D графики использовались программные визуализаторы. Программный рендеринг все еще используется в некоторых инструментах моделирования для рендеринга изображений, для которых визуальная достоверность важнее производительности (количество кадров в секунду) или когда аппаратное обеспечение компьютера не удовлетворяет требованиям, например, не поддерживает шейдеры.

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

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

1.

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

1.1 История возникновения игровых движков

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

Первые примитивные компьютерные и видеоигры были разработаны в 1950-х и 1960-х годах. Они работали на таких платформах, как осциллографы, университетские мейнфреймы и компьютеры EDSAC. Самой первой компьютерной игрой, стал симулятор ракеты, созданный в 1942 году Томасом Голдсмитом Младшим и Истл Рей Менном. Позже, в 1952, появилась программа, играющая в «крестики-нолики», созданная А.С. Дугласом как часть его докторской диссертации в Кембриджском Университете. Игра работала на большом университетском компьютере, известном как EDSAC (Electronic Delay Storage Automatic Calculator). В 1958 году, Уильям Хигинботем, помогавший строить первую ядерную бомбу, в Национальной Лаборатории Брукхевен (Аптон, Нью-Йорк), для развлечения посетителей создал «Теннис для двоих». В 1962 году, Стив Рассел написал «Космическая война и Большое Приключение Джона». Игра работала на миникомпьютере PDP-1 и быстро распространилась по всем университетам страны. В 1968 году, Ральф Баер, который позже стал известен как «Король Видеоигр». запросил патент на раннюю версию игровой консоли «Televisio n Gaming and Training Appataus». В 1967 году, Баер создал пингпинг игру, похожую на «Теннис для двоих». Вместе с Magnavox он работал над созданием первой консоли, названной Magnavox Odyssey в 1972 году. Разработка игровых автоматов в 1970-х привела к так называемому «Золотому веку аркад». Одна из самых известных игр того времени - «Pong».

С появлением первых персональных компьютеров, игры быстро распространились и на этой платформе. И в настоящее время самыми популярными игровыми платформами являются персональные компьютеры и специализированные игровые приставки, такие как PLAYSTATION 3 и Xbox 360.

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

Индустрия создания и продажи движков приобрела поистине широкий размах благодаря развитию 3D-технологий. Реализация низкоуровневых операций работы с графикой и звуком стала очень трудоемкой и дорогостоящей, и многие разработчики предпочитают использовать уже готовые движки для своих игр. Продажа движков стала настолько выгодной, что некоторые разработчики игр занимаются в первую очередь созданием движков, а не игр. Например, цена лицензии на использование известного движка Unreal Engine 2 от компании Epic Games составляет 750000 долларов на одну платформу плюс 100000 за каждую дополнительную платформу, а количество игр, выпущенных на этом движке, перевалило за четыре десятка. Раз так называемый игровой движок является основой для построения игр, попробуем разобраться, что же он из себя представляет.

1.2

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

Игровой движок - это центральный программный компонент компьютерных и видео игр или других интерактивных приложений с графикой, обрабатываемой в реальном времени. Он обеспечивает основные технологии и часто дает игре возможность запускаться на нескольких платформах, таких как игровые консоли и настольные операционные системы, например, Linux, Mac OS и Microsoft Windows.

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

В наиболее широком случае, игровой движок включает в себя: · Систему игровой логики

· Систему ввода и работы в сети

· Систему анимации

· Физический движок или систему навигации и обнаружения столкновения

· Систему искусственного интеллекта

· Звуковой движок

· Скриптовый движок

· Базу данных трехмерных моделей и изображений

· Разнообразные редакторы для работы с движком и создания игры

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

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

Структура игрового движка сильно зависит и от жанра игры, для которой он создается. Например, в гоночных аркадах может не быть развитого физического движка, а только учет сил трения, упругих соударений и импульса. А в некоторых играх физика может составлять часть игрового процесса (геймплея - совокупность игровых возможностей, образующих собственно игровой процесс) данной игры, как например в Half-life 2.

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

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

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

1.3 Графический движок игровой движок приложение программа

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

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

Современный графический движок должен уметь: · Рисовать интерфейс пользователя: · Экранные меню

· Игровой интерфейс

· Рисовать сцену: · Ландшафт

· Объекты

· Модели (с анимацией)

· Окружение (небо, облака, погода и т.д.)

· Эффекты Тени

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

Чаще всего 3D движки или системы рендеринга в игровых движках построены на графическом API, таком как Direct3D или OPENGL, который обеспечивает программную абстракцию GPU или видеокарты. До появления аппаратно-ускоряемой 3D графики использовались программные визуализаторы. Программный рендеринг все еще используется в некоторых инструментах моделирования, для рендеринга изображений, для которых визуальная достоверность важнее производительности (количество кадров в секунду) или когда аппаратное обеспечение компьютера не удовлетворяет требованиям, например, не поддерживает шейдеры или, в случае Windows Vista, - Direct3D 10.

Конвейер рендеринга

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

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

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

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

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

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

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

1.4 Шейдерные эффекты

1.4.1 О шейдерах

Шейдером в широком смысле называется программа для визуального определения поверхности объекта. Это может быть описание освещения, текстурирования, постобработки и т.п. Шейдеры выросли из работ Кука (Cook"s shade trees [12]) и Перлина (Perlin’s pixel stream language). Программируемые шейдеры были впервые представлены в RENDERMAN компании Pixar, там определены несколько типов шейдеров: light source shaders, surface shaders, displacement shaders, volume shaders, imager shaders. Эти шейдеры чаще всего программно выполняются универсальными процессорами и не имеют полной аппаратной реализации. В дальнейшем, многие исследователи описывали похожие на RENDERMAN языки, но они уже были предназначены для аппаратного ускорения. Peercy сотоварищи разработали технику для того, чтобы программы с циклами и условиями выполнять на традиционных аппаратных архитектурах при помощи нескольких проходов рендеринга. Шейдеры RENDERMAN разбивались на несколько проходов, которые комбинировались во буфере кадра. Позднее появились языки, которые были аппаратно ускоренными в Direct X и OPENGL. Так шейдеры были адаптированы для графических приложений реального времени.

Видеочипы раннего времени не были программируемы и исполняли только заранее запрограммированные действия (fixed-function), например, алгоритм освещения был жестко зафиксирован в аппаратном обеспечении, где ничего нельзя было изменить. Затем, компании-производители видеочипов постепенно ввели в свои чипы элементы программируемости, сначала это были очень слабые возможности, которые не получили программной поддержки в Microsoft DIRECTX API, но со временем возможности постоянно расширялись.

Версия Shader Model 2.0 (SM2), появившись в DIRECTX 9, серьезно расширила возможности шейдеров реального времени, предложив более длинные и сложные шейдеры и заметно расширившийся набор команд. Была добавлена возможность расчетов с плавающей запятой в пиксельных шейдерах, что также стало важнейшим улучшением. DIRECTX 9, в лице возможностей SM2, также привнес и язык шейдеров высокого уровня - high-level shader language (HLSL), весьма похожий на язык Си. И эффективный компилятор, переводящий HLSL программы в низкоуровневый код, «понятный» для аппаратных средств

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

Все шейдеры состоях из двух состовляющих: это вершинные и пиксельные шейдеры. Вершинные шейдеры - это программы, выполняемые видео чипами, которые производят математические операции с вершинами, иначе говоря, они предоставляют возможность выполнять программируемые алгоритмы по изменению параметров вершин и их освещению. Каждая вершина определяется несколькими переменными, например, положение вершины в 3D пространстве определяется координатами: x, y и z. Вершины также могут быть о писаны характеристиками цвета, текстурными координатами и т.п. Вершинные шейдеры, в зависимости от алгоритмов, изменяют эти данные в процессе своей работы, например, вычисляя и записывая новые координаты и / или цвет. Таким образом, входные данные вершинного шейдера - данные об одной вершине геометрической модели, которая в данный момент обрабатывается. Обычно это координаты в пространстве, нормаль, компоненты цвета и текстурные координаты. Результирующие данные выполняемой программы служат входными для дальнейшей части конвейера, растеризатор делает линейную интерполяцию входных данных для поверхности треугольника и для каждого пикселя исполняет соответствующий пиксельный шейдер.

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

1.4.2 Программирование шейдерных программ

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

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

Рисунок 1.1 Схема графического конвейера

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

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

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

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

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

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

1.5

Графические API

1.5.1 Обзор API

На сегодняшний день существует три основных API позволяющих программировать графический конвейер: Direct3D, OPENGL и XNA. Каждое из них имеет свои преимущества и недостатки.

OPENGL

OPENGL, является, пожалуй, самым распространенным API для программирования GPU. Он поддерживается большинством современных платформ, к примеру, существуют эффективные реализации OPENGL для таких сред как Windows, Linux, MACOS и PLAYSTATION III. OPENGL был разработан SGI (Silicon Graphics Incorporated), который позже, в 1992 году возглавил консорциум OPENGL ARB (Architecture Review Board) в состав которого сейчас входят такие производители профессиональных и потребительских графических аппаратных средств, как SGI, 3Dlabs, Matrox и Evans & Sutherland, ATI и NVIDIA. Из производителей аппаратного обеспечения входящих в состав ARB можно назвать Intel, IBM, Apple, Dell, Hewlett-Packard и Sun Microsystems. Так же нельзя не упомянуть одного из крупнейших разработчиков игрового программного обеспечения - IDSOFTWARE. Из достоинств OPENGL можно назвать: невероятную гибкость, открытость и расширяемость, а так же упомянутую выше кроссплатформенность. К недостаткам OGL можно, отнести лишь одну, но крайне существенную особенность - крайне медленные темпы развития и обновления версий OPENGL. Это связанно с постоянно возникающими разногласиями и нестыковками между членами консорциума, а это попросту недопустимо в стремительно развивающемся мире графических адаптеров.

Direct3D

Несмотря на то, что все операционные системы семейства Windows, начиная с 95-ой версии, способны превосходно работать с библиотеками OPENGL, Microsoft параллельно ведет разработку и поддержку своего собственного API для программирования графических адаптеров. Direct3D является частью проекта DIRECTX, включающего в себя набор инструментов для работы с мультимедиа, к примеру DIRECTSOUND используется для работы со звуком, DIRECTINPUT и DIRECTPLAY для работы с внешними контроллерами и сетью соответственно. Direct3D, в отличие от OPENGL, не является кроссплатформенными и поддерживается лишь системами Microsoft Windows и Microsoft XBOX. Но благодаря тому факту, что Microsoft регулярно выпускает новые версии DIRECTX, его API всегда поддерживает возможности новейших видеокарт.

The XNA Framework

XNA Framework - самая молодая из троицы API, дата ее выпуска - 2007-ой год. XNA базируется на DIRECTX SDK и предоставляет программисту высокоуровневый объектно-ориентированный функционал для разработки видеоигр. На данный момент XNA официально поддерживает лишь язык C#, так как ее основные библиотеки построены на Microsoft.NET framework. Поддерживаемые платформы - Microsoft Windows и Xbox 360.

1.5.2 Сравнение трех основных графических API

Кросс-платформенная разработка

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

На данный момент больше всего различных платформ поддерживает OPENGL: Microsoft Windows, Linux, Mac. OPENGL не может работать под Xbox и Xbox 360 но поддерживается PLAYSTATION 3.

Direct3D API работает лишь на платформах Microsoft (Windows, Xbox, Xbox 360), а также эмулируется под Linux при помощи платформы Wine, которая перенаправляет вызовы Direct3D API в OPENGL API.

Как уже говорилось выше, XNA Framework работает лишь на тех платформах Microsoft, которые поддерживают.NET framework (т.е. Windows XP, Vista, 7 и Xbox 360).

Простота использования

В терминах синтаксиса кода самым простым для использования будет XNA API, а самым сложным - DIRECTX. Так как DIRECTX и OPENGL - нативные библиотеки C, предоставляемый интерфейс не поддерживает классы и пространства имен.

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

Таким образом, если OPENGL и Direct3D ближе к аппаратному уровню и могут быть портированы на языки высокого уровня, время, затрачиваемое на разработку приложения под эти API, будет значительно больше, чем при использовании XNA.

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

Так как OPENGL и Direct3D - API основанные на С, они ближе к аппаратному уровню, и имеют не так много уровней абстракции. Таким образом, разница в производительности между первым и вторым API несущественны. Если и будут серьезные различия, то это будет скорее всего вызвано тем, как драйвер видеокарты выполняет команды API.

XNA Framework - это библиотека.NET, которая выполняет вызовы Direct3D на виртуальной машине, в которой.NET Framework работает. Такой высокий уровень абстракции может привести в потерям производительности.

Свойства

API часто ограничены количеством свойств, которые они имеют на момент выпуска. Это приводит к тому, что API постоянно обновляются, увеличивая номер в названиях версии. Новые версии SDK для DIRECTX/Direct3D выпускаются каждые несколько месяцев.

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

XNA Framework основана на 9-ой версии Direct3D и содержит лишь функционал этого API. Если новая версия Direct3D выпускается, XNA получит обновление лишь позже, серьезно уступаю в этом плане другим API.

Поддержка

OPENGL API поддерживается исключительно сообществом разработчиков. DIRECTX API поддерживается как сообществом разработчиков, так и авторами API через MSDN. XNA Framework также имеет профессиональную поддержку аналогичную DIRECTX.

Популярность

Direct3D API наиболее популярное решение для платформ Windows и Xbox, а то есть для большинства разработчиков игр.

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

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

Лицензия

Очень важным аспектом в разработке программ - это лицензионные ограничения, накладываемые на API. OPENGL и Direct3D имеют лицензионные модели, которые позволяют выпускать коммерческие продукты без ограничений.

Для выпуска продукта под XNA Framework должно быть заключено лицензионное соглашение между разработчиком и Microsoft, которое ограничивает использование сетевых функций XNA. XNA Game Studio не может быть использована для разработки коммерческих игр под Xbox 360, но выпуск игр под Windows разрешен. Чтобы выпускать игры под Xbox 360, существует специальная подписка для разработчиков, размером в $99.

Таблица 1: Сравнение трех основных графических API

Свойства OPENGL Direct3D XNA

Поддержка различных платформ, число Да, множество Да, три Да, две

Сложность освоения Высокая Высокая Низкая

Базовый язык (нативный) C C C#

Поддерживаемые языки Большинство языков Большинство языков NET языки

Высокая производительность Да Да Нет

Лицензионные ограничения Нет Нет Да Поддержка производителем Нет Да, платно Да, платно

Платформа Библиотеки Нативный код Нативный код Управляемый код

1.5.3 Общие принципы работы с графическими API

Direct3D и OPENGL имеют ряд серьезных различий в их структуре и наборе предоставляемых функций, но тем не менее они выполняют одну и ту же роль, а именно подготавливают систему для исполнения кода шейдера на GPU [7]. Этот процесс в общих чертах может быть разбит на следующие этапы: 1. Создание графического устройства (device) представляющее собой своеобразную программную модель графического процессора. Именно через него осуществляется почти работа с GPU.

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

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

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

5. Загрузка в память графического адаптера всех матриц и констант, необходимых для исполнения эффекта. На данном этапе так же происходит ассоциация самплеров (sampler) эффекта с ранее загруженными текстурами.

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

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

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

1.6 Теоретический обзор шейдерных эффектов

1.6.1 Равномерное освещение

Равномерное освещение (ambient lighting) обеспечивает постоянное начальное освещение для всей сцены. Оно освещает все вершины объектов одинаково, потому

Разработана и реализована архитектура библиотеки классов, способная отрисовывать любые трехмерные сцены с использованием основных алгоритмов обработки. В библиотеке реализованы следующие алгоритмы 3D-графики: освещение объекта (равномерное, диффузное, бликовое), текстурирование, Shadow Mapping, вывод в квадрат любой текстуры, создание и управление навигацией камеры, загрузка и визуализация сложных 3D моделей, настройка материалов, загрузка, выгрузка и передача данных в шейдеры. Создано демонстрационное приложение с использованием этой библиотеки. Кроме того, данный набор библиотек может служить основой для разработки коммерческой системы моделирования, а само приложение может быть использовано в качестве учебного материала по дисциплине компьютерная графика.

Горнаков С.Г. DIRECTX 9: «Уроки программирования на С ». - СПБ.: БХВ-Петербург, 2005. - 400 с.

Программирование игр на платформе XNA [Электронный ресурс]. - Режим доступа: http://www.xnadev.ru свободный.

Luna, Frank D. Introduction to 3D game programming with DIRECTX 9.0. - Wordware Publishing, Inc, 2003. - 421 p. ixbt.com [Электронный ресурс]. - Режим доступа: http://www.ixbt.com свободный.

Blinn, James F. Simulation of Wrinkled Surfaces // Computer Graphics, Vol. 12 (3), pp. 286-292, SIGGRAPH-ACM (August 1978).

Dempski, Kelly and Viale, Emmanuel, Advanced Lighting and Materials with Shaders // Wordware Publishing Inc., 2005, 361 p.

Программирование игр [Электронный ресурс]. - Режим доступа: http://www.gamedev.ru свободный.

Nitschke B. Professional XNA Game Programming: For Xbox 360 and Windows - Wrox Press, 2007. - 504 p.

Krishnamurthy and Levoy, Fitting Smooth Surfaces to Dense Polygon Meshes // SIGGRAPH 1996.

Guardado, Juan, NVIDIA, GPU Gems, 2004 by NVIDIA Corporation.

Pharr, Matt and Fernando, Randima, NVIDIA, GPU Gems 2: Programming Techniques for High-Performance Graphics and General-Purpose Computation, 2005, by Addison-Wesley Professional, 880 p.

Cook, Robert L., Shade trees // Proceedings of the 11th annual conference on Computer graphics and interactive techniques, p. 223-231, January 1984, SIGGRAPH-ACM.

Phong, Bui-Tuong, Illumination for computer generated images // Comm. ACM 18, 6 (June 1975) 311-317.

Blinn, James F., Models of Light Reflection for Computer Synthesized Pictures // Computer Graphics, Vol. 11, No. 2, July, 1977, 192-198.

Krishnamurthy and Levoy, Fitting Smooth Surfaces to Dense Polygon Meshes // SIGGRAPH 1996

Cohen et al., Appearance-Preserving Simplification // SIGGRAPH 1998

Cignoni et al., A general method for recovering attribute values on simplifed meshes // IEEE Visualization 1998

Oliveira, Manuel M.; Bishop, Gary; MCALLISTER, David, Relief texture mapping // International Conference on Computer Graphics and Interactive Techniques archive, proceedings of the 27th annual conference on Computer graphics and interactive techniques, Pages: 359 - 368, 2000.

Kaneko, T., et al., Detailed Shape Representation with Parallax Mapping // In Proceedings of ICAT 2001, pp. 205-208, 2001.

Crow, F., Shadow algorithms for computer graphics, // SIGGRAPH, vol. 11, 242-248, 1977.

Roth, Scott D., Ray Casting for Modeling Solids // Computer Graphics and Image Processing 18: 109-144, doi:10.1016/0146-664X(82) 90169, February 1982.

Jensen, Realistic Image Synthesis Using Photon Mapping // AK Peters, July 2001.

Williams, Lance; Casting curved shadows on curved surfaces // SIGGRAPH-ACM, Volume 12, Issue 3 (August 1978), pp: 270 - 274., 1978.

Spencer, Greg; Shirley Peter; Zimmerman, Kurt; Greenberg, Donald P.; Physically-based glare effects for digital images // SIGGRAPH: 325. doi:10.1145/218380.218466., 1995.

Debevec, Paul E. and Malik Jitendra, Recovering High Dynamic Range Radiance Maps from Photographs // SIGGRAPH, 1997.

Размещено на