Разрабокта расширения для игрового движка Unity
Игровой движок Unity, его использование для создания приложений, связанных с архитектурой, обучением, визуализацией данных и электронными книгами. Разработка системы освещения для работы с двухмерными объектами в виде расширения редактора Unity.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | дипломная работа |
Язык | русский |
Дата добавления | 11.02.2017 |
Размер файла | 2,5 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Содержание
- Введение
- 1. Актуальность работы
- 2. Цели и задачи работы
- 3. Обзор аналогов
- 3.1 2D Light System
- 3.2 2D Dynamic Lights and Shadows
- 3.3 Light2D - GPU Lighting System
- 3.4 Light2D
- 3.5 2DVLS (2D Volumetric Lights and Shadows)
- 3.6 Seasons After Fall Rendering System
- 3.7 Игровой движок Ethanon 2D
- 3.8 Система освещения Unity
- 4. Компоненты разрабатываемой системы
- 4.1 Планы
- 4.2 Объекты
- 4.3 Источники света
- 4.3.1 Ambient Light
- 4.3.2 Directional Light
- 4.3.3 Point Light
- 4.3.4 Spot Light
- 4.3.5 Area Light
- 4.3.6 Emissive Objects
- 4.4 Система расчета теней
- 4.4.1 Расчет внешних теней
- 4.4.1.1 Метод трассировки лучей
- 4.4.2 Форма теней
- 4.4.3 Внутреннее освещение
- 4.5 Запекание света
- 4.6 Менеджер освещения
- 4.7 Графический интерфейс
- 4.8 Документация
- 5. Реализация системы в Unity
- 5.1 Реализация объектов
- 5.2 Источники освещения
- 5.2.1 Ambient Light
- 5.2.2 Point Light
- 5.2.2.1 ShadowMap
- 5.2.2.1.1 Определение, находится ли источник внутри объекта
- 5.2.2.1.2 Поиск базовых и вспомогательных точек
- 5.2.2.1.3 Поиск крайних точек
- 5.2.2.1.4 Формирование четырехугольников
- 5.2.2.1.5 Поиск корректирующих коэффициентов для задания UV координат
- 5.2.2.1.6 Поиск "точек привязки"
- 5.2.2.1.7 Наложение текстуры тени
- 5.2.2.2 MaterialSettings
- 5.2.2.3 IsInsideArea
- 5.2.3 Spot Light
- 5.2.3.1 ShadowMap
- 5.2.3.2 IsInsideArea
- 5.2.4 Directional Light
- 5.2.4.1 ShadowMap
- 5.2.4.2 MaterialSettings
- 5.2.4.3 IsInsideArea
- 5.2.5 Area Light
- 5.2.5.1 ShadowMap
- 5.2.5.2 MaterialSettings
- 5.2.5.3 IsInsideArea
- 5.3 Плановость
- 5.4 Шейдер
- 5.5 Интерфейс
- 5.5.1 Point Light
- 5.5.2 Spot Light
- 5.5.3 Directional Light
- 5.5.4 Area Light
- 5.6 Документация
- Заключение
- Список использованных источников
- Приложения
Введение
Игровой движок Unity очень популярен среди разработчиков видеоигр, особенно среди начинающих, из-за простоты освоения и бесплатности. Несмотря на то, что движок ориентирован на трехмерные приложения, он поддерживает работу с двухмерной графикой. Однако не все компоненты редактора одинаково хорошо работают в 3D и 2D. В частности, встроенная система освещения не позволяет двухмерным объектам служить полноценным препятствием для света и отбрасывать тени на другие объекты. На Рис. 1 представлены три типа объектов в редакторе Unity: куб, четырехугольник и двухмерный спрайт.
Рис. 1 Тени, отбрасываемые различными типами объектов Unity. 1) Общий вид сцены. 2) Объекты имеют координату z равную - 0.5, источник света - 1.5 3) Координаты z объектов и источника равны - 0.5
Ко всем объектам прикреплен одинаковый материал с одинаковым шейдером. Если куб является полноценным препятствием для света, то четырехугольник отбрасывает тень только от тех источников, которые не лежат в одной плоскости с ним, а спрайт и вовсе игнорируется системой расчета теней. В трехмерном пространстве это обусловлено физическим расчетом освещаемых областей, так как четырехугольник, в отличие от куба, не имеет толщины, однако в двухмерном пространстве объемные фигуры представлены плоскими 2D объектами, поэтому необходимо обеспечить возможность взаимодействия со светом двухмерных объектов, идентичную взаимодействию трехмерных в 3D пространстве.
игровой движок unity освещение
1. Актуальность работы
В последнее время Unity развивается стремительными темпами, привлекая все больше новых разработчиков. На базе этого движка были созданы такие популярные игры, как Ori and the Blind Forest (разработчик: Moon Studios), Cities: Skylines (разработчик: Colossal Order), Dungeon of the Endless (разработчик: Amplitude Studios) [1], а также мобильная версия Hearthstone: Heroes of Warcraft (разработчик: Blizzard Entertainment) [2]. Кроме того, Unity используется для создания приложений, связанных с архитектурой, обучением, визуализацией данных, электронными книгами и многими другими отраслями [3]. Так при съемках фильма Книга джунглей (2016, режиссёр: Джон Фавро) приложение на базе Unity Engine использовалось для визуализации в режиме реального времени перемещения по сцене и работы с освещением [4].
Примеры инструментов для работы с 2D освещением существуют, но, как правило, они либо определяют форму объекта через специальные компоненты Unity - коллайдеры, которые служат для обработки столкновений, и не всегда их применение возможно у данного объекта, либо, создавая области тени, отбрасываемой каким-либо объектом, не освещают сам объект.
2. Цели и задачи работы
Цель работы: Разработать и реализовать систему освещения для работы с двухмерными объектами в виде расширения редактора Unity.
Задачи
- Рассмотреть аналоги разрабатываемой системы;
- Сформировать список требований;
- Изучить основы освещения;
- Реализовать основные источники освещения;
- Реализовать систему расчета теней, как отбрасываемых объектами, так и внутренних;
- Обеспечить графический интерфейс для управления системой в окне редактора Unity;
- Составить документацию для пользователей системы.
3. Обзор аналогов
В качестве аналогов разрабатываемой системы были рассмотрены:
- Готовые системы, опубликованные в Unity Asset Store:
- 2D Light System (Автор: Михаил Любимов);
- 2DDL PRO - 2D Dynamic Lights and Shadows (Автор: Martin Ysa);
- Light2D - GPU Lighting System (Автор: Alexander Penkin);
- Light2D (Автор: Dan John Moran);
- 2DVLS (на данный момент эта система не доступна) (Автор: Pico Games);
- Реализованные системы освещения:
- Seasons After Fall Rendering System (разработчик: Swing Swing Submarine);
- Игровой движок Ethanon 2D;
- Система освещения Unity.
К сожалению, большинство вышеупомянутых систем требуют покупки для их использования. Поэтому, обзор функционала некоторых из них выполнялся на основе комментариев пользователей, видео-демонстраций и тестовых сцен.
3.1 2D Light System
Данная система является самой мощной из рассмотренных. Она поддерживает три типа источников освещения: Point Light, Spot Light и Directional Light, а также Ambient Light.
Тени отбрасываются не только стандартными 2D объектами, но и системой частиц. Также в данном продукте реализован эффект преломления света при прохождении через прозрачные области. Для формирования тени система использует альфа-канал объекта, а не систему коллайдеров. Поддерживаются мягкие тени. Основными недостатками пользователи этого продукта называют: отсутствие поддержки со стороны разработчика, работа только в плоскость xy, невозможность управлять порядком прорисовки теней объектов [5].
3.2 2D Dynamic Lights and Shadows
Данная система формирует тени объектов путем трассировки лучей от источника света к определённым точкам на сцене. Эти точки задаются как формой освещаемой области (источник представляет собой восьмиугольник, отображенный при помощи специального шейдера), так и вершинами объектов. Существенный минус этой системы заключается в том, что эти углы определяются так называемыми коллайдерами [6]. Система коллайдеров Unity используется в первую очередь для определения столкновений объектов. В данном случае это значит, что не все объекты, имеющие данный компонент, должны служить препятствием для света, и не все препятствия, в свою очередь, должны обладать данным компонентом.
3.3 Light2D - GPU Lighting System
Данная система обладает следующими функциями:
- Поддержка Normal mapping;
- Оптимизация для мобильных устройств;
- Отсутствие необходимости в использовании коллайдеров для формирования тени;
- Свободное изменение формы источника света;
- Точечный, линейный, окружающий источники;
- Поддержка системы частиц.
Для формирования освещенной области используются спрайты. Освещение формируется с использованием дополнительной камеры, которая должна быть в 1-1,5 раза больше основной. В то же время, работа с перспективной камерой поддерживается лишь частично [7].
3.4 Light2D
Тени, формируемые этой системой, зависят от формы коллайдера объекта. В то же время, система имеет достаточно удобный пользовательский интерфейс для настройки параметров источников освещения. Кроме того, в данном продукте реализована система автоматического объединения источников, имеющих одинаковый материал, что сокращает число необходимых вычислений [8].
3.5 2DVLS (2D Volumetric Lights and Shadows)
Основная идея этой системы заключается в задании геометрии объекта вручную. Это несколько похоже на систему коллайдеров, описанную ранее, но их работе такая система не мешает. Пользователь создает и перемещает вершины многоугольника, которые, соединяясь последовательно, формируют контур объекта. В данном продукте реализованы точечный источник света и источник произвольной формы. Работают они по сходному алгоритму, но форма первого представляет из себя правильный многоугольник с заданным количеством граней, а область освещения второго типа задается тем же способом, что и силуэт освещаемых объектов. Кроме того, источники могут изменять угол освещаемого сектора, тем самым моделируя Spot Light. Освещение объектов рассчитывается при помощи аддитивного шейдера, используемого полигоном источника [9].
3.6 Seasons After Fall Rendering System
Французская компания Swing Swing Subrarine представила систему освещения для своей игры Seasons After Fall на конференции Game Connection Paris. Основным компонентом системы являются так называемые планы (слайсы). Суть данной системы заключается в разделении сцены на несколько планов по аналогии с живописью (задний план, передний план и т.д.). Ключевой особенностью является то, что каждый план имеет собственное освещение, эффекты, действующие на весь план, и собственное значение окружающего света. Источники освещения и тени формируются на основе их собственной системы формирования спрайтов. Освещение слайса формируется объединением двух карт освещения - передней и задней. Такая система позволяет использовать неограниченное количество источников. С другой стороны, она не позволяет использовать карты нормалей [10].
3.7 Игровой движок Ethanon 2D
Ethanon 2D - Полноценный игровой движок, сфокусированный на поддержке высококачественного освещения. Из источников освещения представлены только точечные. Поддерживается работа с тенями от 2D объектов и импортированных 3D. Настройка ширины затеняемой области производится отдельно и не зависит от формы объекта [11].
3.8 Система освещения Unity
Система освещения Unity состоит из источников освещения, системы запекания света, системы шейдеров и системы глобального освещения. Все отображаемые объекты имеют свой компонент-рендерер, к которому прикреплен материал. Материал представляет собой шейдер, параметры которого можно настраивать. Шейдеры могут быть написаны пользователями, а могут быть выбраны из стандартных. Для объявления переменных и описания функций расчета освещения используются специальные файлы с расширением. cginc.
Источники освещения являются объектами с прикрепленным к ним специальным компонентом. Unity поддерживает следующие типы источников освещения:
- Point light
- Spot light
- Directional light
- Area light
Каждый из них обладает собственным набором атрибутов. Информация об источниках передается в шейдеры автоматически специальным потоком, однако у пользователей нет доступа к исходным кодам движка, из-за чего управлять этим процессом затруднительно.
Таким образом, разрабатываемая система должна включать в себя как минимум следующие функции:
- Поддержка источников освещения, подобных источником редактора Unity
- Система расчета теней для всех типов 2D объектов
- Расчет теней в режиме реального времени в окне редактора
- Работа в плоскости XY
- Работа без привязки к системе коллайдеров
- Графический интерфейс для настройки компонентов системы
- Поддержка шейдеров для расчета освещения объектов
Помимо этого, в расширении будет реализована система планов на подобии системы Swing, swing, submarine и специальная система для задания формы тени, отбрасываемой объектами. Для удобства использования система должна быть тщательно документирована.
4. Компоненты разрабатываемой системы
Сцена в редакторе Unity представляет собой набор объектов, к каждому из которых прикреплены какие-либо компоненты. Разрабатываемые пользователями компоненты представлены в виде скриптов, написанных на одном из двух языков программирования - C# или JavaScript. Любой отображаемый на сцене объект имеет свой компонент-рендерер, отвечающий за его рендеринг. Данный компонент одним из своих атрибутов имеет материал, к которому прикреплен определенный шейдер. Шейдер отвечает за то, как непосредственно объект будет отрисовываться на сцене, и как он будет взаимодействовать со светом. Шейдеры в Unity могут быть написаны, используя следующие языки (иногда реализация одного шейдера состоит из нескольких частей, написанных на разных языках программирования): HLSL, GLSL, Cg. Рассмотрим предполагаемую сцену Unity при использовании разрабатываемой системы. Сцена по аналогии с системой, предложенной компанией Swing Swing Submarine, разделена на так называемые планы. Каждому из них принадлежит множество объектов и источников освещения. К объектам привязаны материалы, к которым прикреплены шейдеры. Менеджеры планов собирают информацию о своих источниках освещения и передают её в качестве параметров в шейдеры.
Теперь подробнее о каждом компоненте системы.
4.1 Планы
В разрабатываемой системе предполагается реализация системы планов, подобно системе французской компании-разработчика Swing Swing Submarine. Плановость предполагает разделение сцены на слои, подобно планам, например, в живописи: задний план, средний план, передний план (Рис. 2).
Рис. 2 Система плановости в изобразительном искусстве
Естественно количество планов на сцене не должно ограничиваться тремя, так разработчики Swing Swing Submarine используют следующее разделение: background 2, background 1, playground foreground [10] (Рис. 3).
Рис. 3 Разделение игровой сцены на планы в игре Seasons after Fall
Основная идея реализации планов заключается в том, что каждый из них имеет собственное, независимое освещение. Так источники одного плана никак не взаимодействуют с объектами другого. Это верно не только для источников, размещаемых непосредственно на сцене, но и для значения окружающего света (Ambient Light). Итоговая сцена формируется последовательным наложением планов друг на друга, как показано на Рис. 4 [10].
Рис. 4 Процесс формирования итоговой сцены, состоящей из четырех планов
Несмотря на то, что это можно было бы частично моделировать расположением групп объектов на большом расстоянии по оси z друг от друга, такой метод реализации не поддерживал бы различные настройки Ambient Light и Directional Light в разных слайсах.
Внутри одного плана тоже необходимо каким-либо образом определять глубину. Для этого можно использовать несколько параметров, реализованных в Unity: порядок прорисовки объекта в слое и значение z-координаты объекта. Так как многие объекты в сцене представлены несколькими спрайтами, и для правильного их отображения требуется определить порядок их прорисовки, то использовать параметр порядка в слое затруднительно. Однако, Unity изначально является трехмерным движком, и даже в двухмерном режиме у нас есть возможность распределять объекты вдоль оси z.
Предлагается следующая модель взаимодействия света с объектами, в зависимости от их взаимного расположения по оси z (Рис. 5). Объект, находящийся над источником света (ближе к камере), не освещается им и не отбрасывает теней. Объект под источником также не отбрасывает теней, но освещается. Объект, находящийся на одном уровне с источником (имеющий то же значение координаты z), не освещается, но является препятствием для прохождения света, отбрасывая тень на все, что находится за ним.
Рис. 5 Взаимодействие источника освещения с объектами, в зависимости от их взаимного расположения
4.2 Объекты
Двухмерные объекты в Unity можно разделить на два типа по классу их компонента-рендерера (указан в скобках).
- Спрайты (SpriteRenderer);
- Полигоны (MeshRenderer), то есть quad и plane.
В зависимости от задач разрабатываемого приложения, могут использоваться объекты любой из групп, поэтому необходимо обеспечить работу разрабатываемой системы с обоими типами. Предполагается, что у объектов задан некоторый материал, к которому прикреплен соответствующий шейдер, отвечающий за расчет внутреннего освещения компонента.
Так как двухмерный объект представлен на сцене четырехугольной фигурой с наложенной на неё текстурой, определение формы освещаемого изображения на основе координат четырех вершин приведет к появлению неточностей в формировании области затенения. Таким образом, необходимо опираться либо на значение альфа-канала текстуры, либо на заданную отдельно геометрию объекта. Так как предполагается, что в разрабатываемой системе будет возможность задать форму тени, а для этого требуется знать координаты вершин, определяющих тень, о чем будет описано далее, был выбран второй вариант.
4.3 Источники света
Освещение любого объекта зависит от источников света, расположенных на сцене. По аналогии с системой освещения Unity можно выделить следующие типы источников.
4.3.1 Ambient Light
Ambient light симулирует освещение, полученное за счет многократного отражения света от поверхностей окружающих объектов. Технически, Ambient light освещает все точки сцены с одинаковой интенсивностью и как правило является константой. В разрабатываемой системе данный источник освещения задается индивидуально для каждого плана.
Основным параметром Ambient Light является цвет.
4.3.2 Directional Light
Directional light излучает свет в виде бесконечного множества бесконечно удаленных от объектов и направленных под определенным углом лучей (Рис. 6). Как правило, Directional Light используется для моделирования солнечного света.
Данный тип источника не имеет позиции в пространстве, радиуса действия, и интенсивность освещения не падает с удалением объекта от источника.
Рис. 6 Направление распространения света Directional Light
Основными параметрами Directional Light являются угол поворота, цвет и интенсивность.
4.3.3 Point Light
Point light излучает свет одинаково во всех направлениях из определенной точки пространства. Интенсивность света падает с удалением от этой точки (Рис. 7). Данный источник используется для моделирования света от ламп, костров и подобных ненаправленных источников.
Рис. 7. Распространение света в пределах радиуса Point Light
Основными параметрами Point Light являются позиция, радиус, цвет и интенсивность.
4.3.4 Spot Light
Spot light очень похож на Point light. Отличие заключается в том, что в данном источнике освещения есть приоритетное направление излучения света. То есть, если освещаемую область point light можно представить в виде сферы (круга в 2D пространстве), то spot light освещает только некоторый заданный сектор. Этот тип может моделировать свет фонаря, прожектора и других направленных источников.
Рис. 8 Распространение света в пределах радиуса и заданного угла Spot Light
Основными параметрами Spot Light являются позиция, угол поворота, радиус, угол освещаемого сектора, цвет и интенсивность [12].
4.3.5 Area Light
В отличие от ранее описанных типов источников, Area Light излучает свет равномерно по определенной площади.
Поэтому у освещенных объектов появляются области как полной тени, так и полутеней. Расчет освещения от такого источника - достаточно ресурсоемкая задача, из-за этого принимаются различные упрощения, как например расчет нескольких теней с их последующим размытием [13].
С точки зрения расчетов, интенсивность света затухает подобно Point light по мере удаления от области, освещаемой источником (Рис. 9) [14].
Рис. 9 Область затухания света Area Light
В данной работе, предполагается, что Area Light освещает некоторую область равномерно, подобно Directional Light, направленному параллельно лучу наблюдения. Таким образом, основными параметрами данного источника будут цвет, интенсивность, позиция, а также длина и ширина освещаемой площади.
4.3.6 Emissive Objects
Некоторые поверхности сами по себе представляют источники освещения. Это значит, что их освещенность всегда максимальна, независимо от наличия рядом других источников. Для достижения данного эффекта применяются специальные шейдеры [13]. В данной работе подобный тип освещения не рассматривается.
Кроме позиции, цвета и интенсивности, все источники освещения имеют еще один общий атрибут - Cookie. Он представляет собой черно-белую текстуру, задающую уровень освещенности в конкретной точке. Так, если точке в пространстве соответствует белая область Cookie, она освещается полностью, если черная, находится в тени, независимо от того, действительно ли попадает эта точка в тень от какого-то объекта. Такая маска позволяет задавать источники нестандартной формы, или тени от объектов, неотображаемых на сцене.
4.4 Система расчета теней
Одним из самых важных элементов системы освещения является система расчета теней. Существует два типа теней:
- Hard-edged (жесткие тени)
- Soft-edged (мягкие тени)
Мягкие тени состоят из двух регионов: полутень и полная тень. Полная тень представляет собой неосвещенные регионы, в то время как полутень отображает частично затененные области. Жесткие тени включают в себя только полные тени [13].
Так как в работе будут представлены точечные источники освещения, то будут рассмотрены только жесткие тени.
Дополнительно, в 2D пространстве тени можно классифицировать на внешние и внутренние. Под внешними подразумеваются затененные области на других объектах, находящихся в тени от рассматриваемого. Внутренние - те тени, которые объект отбрасывает сам на себя. Так как двухмерные объекты по определению являются плоскими фигурами, второй класс теней реализуется шейдерами при помощи дополнительных карт, задающих рельеф объекта.
4.4.1 Расчет внешних теней
Существует два основных способа формирования теней от источника [12]:
- При помощи Shadow Maps
- Используя Stencil Shadows
Карты теней (Shadow Maps) получаются за счет пофрагментного теста глубины из точки видимости камеры. Сначала, сцена рендерится из зоны видимости источника освещения, и полученные результаты записываются в буфер глубины. После это, сцена отображается как обычно, но по сгенерированной на предыдущем этапе карте определяется, находится ли данный пиксель в тени или нет.
Для каждого вертекса каждого треугольника считается его позиция в относительно источника света. Если этот фрагмент располагается дальше, чем соответствующий ему фрагмент карты теней, то он находится в тени [13].
Так как эта техника основана не на геометрии объектов, а на их отображении, она может быть использована для работы с объектами, имеющими альфа-канал [12].
Stencil Shadows (или Shadow Volumes) - техника, формирующая области, затененные отбрасывающими тени объектами. Она позволяет отображать высоко детализированные тени, качество которых зависит только от полигонального представления объектов [12]. Силуэт объекта, отбрасывающего тень, как бы вытягивается в сторону от источника света. Иными словами, на основе видимой источником геометрии объекта формируется объем, точки внутри которого находятся в тени.
Первый метод подходит и для работы в двухмерном пространстве, однако он не позволяет определять непосредственно точки, формирующие область тени объекта. Используя эти точки можно было бы задавать тени определенную форму.
Второй способ требует наличия полигонов у обрабатываемых объектов. Однако, 2D спрайты состоят из двух треугольников, чего не достаточно для формирования теней не четырехугольных фигур. Так как у пользователей нет доступа к потоку передачи информации в шейдеры Unity, и получить данные о сцене из шейдера не представляется возможным, то расчеты затененных областей приходится производить заранее. Таким образом, необходимо сформировать карту теней одним из двух методов:
- При помощи трассировки лучей;
- При помощи детализации геометрии объекта.
4.4.1.1 Метод трассировки лучей
При помощи трассировки лучей, можно искать переходы от пустых областей к объектам и наоборот (Рис. 10.1 - 10.5) и запоминать эти точки. После этого, для каждого объекта формируется четырехугольник, у которого две вершины имеют координаты найденных на предыдущем шаге точек, а две расположены таким образом, чтобы лежать на одной прямой с соответствующей точкой из первых и центром текстуры (Рис. 10.7 - 10.8).
Рис. 10 Алгоритм расчета теней методом трассировки лучей
Однако данная технология работает достаточно эффективно только, если объекты представлены выпуклыми многоугольниками, и на одном спрайте расположен только один объект. В противном случае, алгоритм сформирует тени, которые не будут соответствовать действительности. (Рис. 11.1 - 11.5) На Рис. 11.6 красным цветом выделены возникающие ошибки в данном случае.
Рис. 11 Ошибки при формировании теней
Для того, чтобы избежать подобной ситуации, предлагается использовать вышеописанный алгоритм для нахождения точек начала и конца затененных областей, но расчет теней внутри производить непосредственно методом трассировки лучей. Для этого из каждой точки найденного ранее сектора, следует пустить луч по направлению к источнику освещения. Если этот луч пересечет какой-либо объект, это будет значить, что точка находится в тени. В противном случае, ничего не загораживает точку от источника, и, соответственно, она считается освещенной. Результат представлен на Рис. 12.
Использование трассировки лучей для каждого пикселя изначально возможно, однако это добавляет определенное количество лишних вычислений. Кроме того, определяемые алгоритмом точки необходимы для формирования теней заданной формы.
Рис. 12 Корректные тени от объектов
4.4.1.2 Метод детализации геометрии объекта
Несмотря на то, что 2D объекты не имеют как таковой геометрии, можно, определив края объектов, создать несколько ключевых точек, которые будут заменять в алгоритме расчета теней вершины трехмерных моделей. (Рис. 13.1).
Проводя лучи от источника освещения к этим точкам, можно по наличию пересечения с контуром какого-либо объекта судить, находится ли эта точка в тени. После этого, останется только построить тень, используя точки для формирования полигонов (Рис. 13.2 - 13.4).
Рис. 13 Расчет теней методом детализации геометрии объекта
4.4.2 Форма теней
Так как в двухмерном пространстве зритель смотрит на сцену преимущественно под одним углом, может возникнуть ситуация, при которой будет практически невозможно однозначно сказать, какую форму имеет объект. Несколько трехмерных объектов могут иметь одинаковую по форме проекцию на плоскость камеры. Например, на Рис. 14.1 представлены две фигуры: параллелепипед (слева) и цилиндр (справа), однако без теней их сложно отличить друг от друга (Рис. 14.2). Но по форме тени (Рис. 14.3) можно сделать вывод о скрытой от глаз части объекта и, тем самым, более точно определить форму фигуры. Более того, то же самое касается наличия в объекте, например, каких либо отверстий (Рис. 15.1 - 15.3).
Рис. 14 Форма теней двух разных объектов
Рис. 15 Форма теней для объекта с отверстием
Для того, чтобы получить тень заданной текстурой формы (Рис. 16.2), требуется знать четыре точки, по которым будет сформирован меш. Предполагается, что эти точки будут получены в результате работы алгоритма предыдущего шага. На полученный полигон накладывается текстура тени. (Рис. 16.1 - 16.3)
Рис. 16 Задание формы тени текстурой
4.4.3 Внутреннее освещение
Освещение самих объектов вычисляется шейдерами, прикрепленными к ним.
Шейдеры должны, получая параметры необходимых источников, обеспечивать освещение объектов. Формула расчета освещенности зависит от выбранной модели.
Предполагается, что функции расчета освещения в разных моделях, использования карт нормалей и др. будут описаны в специальном cginc файле, который будет подключаться к шейдерам. Cginc файлы в Unity являются по сути заголовочными для шейдеров, написанных на языке Cg. В них предполагается описывать необходимые для использования в системе переменные и реализовывать требуемые функции. Таким образом, процесс написания непосредственно шейдера объекта будет заключаться в подключении этого файла и выборе соответствующих правил расчета освещения. Для получения оптимального списка функций следует ориентироваться на cginc файлы Unity.
4.5 Запекание света
Достаточно часто объекты и источники на сцене статичны, и рассчитывать освещение для них каждый кадр представляется довольно затратной операцией. В таких случаях используется система запекания света, заключающаяся в том, что карты теней статичных источников относительно статичных объектов сохраняются в виде карт освещения. Последние используются для определения освещенности объектов без необходимости повторных вычислений.
Несмотря на то, что в данной работе не предусматривается разработка полноценной системы запекания света, статические источники, единожды рассчитав карту теней для статических объектов, не будут повторять этот процесс далее.
4.6 Менеджер освещения
Менеджер освещения - необходимый компонент для организации работы системы. Предполагается, что каждому плану соответствует свой объект-менеджер. Так как из шейдера мы не можем получить информацию о расположенных на сцене компонентах, менеджер является единственным объектом на сцене, который хранит информацию, какой объект каким источником освещен. В задачи этого компонента входит передача необходимых параметров от источников в шейдеры. Кроме того, менеджер следит за тем, чтобы освещение рассчитывалось только для динамичных объектов и источников, которые в данный момент попадают в угол обзора камеры.
4.7 Графический интерфейс
Для удобства работы с системой необходимо обеспечить эффективный инструмент для настройки её компонентов. Для этого:
- создание объектов должно быть доступно из меню редактора;
- параметры, не предполагающие ручной настройки, должны быть скрыты;
- необходимо обеспечить возможность настраивать некоторые параметры источников освещения в окне сцены. Такие параметры должны иметь графическое отображение;
- Для удобства поиска источников освещения на сцене, они должны иметь собственную иконку.
4.8 Документация
Поскольку система будет использоваться сторонними разработчиками, требуется создать руководство по использованию всех компонентов системы. Кроме того, необходимо описать все функции разрабатываемого cginc файла, так как, несмотря на то, что в основном там будут содержаться функции cginc файлов Unity, документации последних пока не существует.
5. Реализация системы в Unity
5.1 Реализация объектов
К сожалению, Unity не позволяет создавать наследников класса Renderer, соответственно, написать собственный класс для отображения двухмерных объектов невозможно. Так как предполагается, что для использования объектов в нашей системе требуется определить некоторые дополнительные параметры каждого из них, был написан скрипт, который необходимо прикрепить к спрайту или четырехугольнику, чтобы они могли полноценно взаимодействовать с системой.
Так как в системе предполагается функция построения теней заданной формы, необходимо вычислять точки для формирования области тени. Для этого лучше подходит алгоритм формирования теней методом детализации геометрии объекта.
Так как двухмерные объекты в трехмерной пространстве как правило представляют из себя четырехугольники, состоящие из двух треугольников, то использовать данные вершины для определения формы препятствия практически невозможно. Именно поэтому геометрия спрайтов задается пользователем. Для этого используется библиотека VLS2D, реализованная в системе, описанной в пункте 3.5 данной работы.
При прикреплении к объекту необходимого компонента, создаются четыре начальных точки. В окне редактора они соединяются гранями. При нажатии клавиши Ctrl на клавиатуре, пользователь может создать точку в любом месте одной из граней. Координаты этой вершины добавляются в лист, между соседними. Удаление точки происходит при помощи кнопки Backspace. Выделенные точки можно переносить тем же образом, что и стандартные объекты на сцене. Таким образом, создавая и располагая вершины, пользователь системы может задавать контуры освещаемого объекта. Если есть необходимость получить специальный эффект, необязательно делать контур идентичным действительной границе изображения. Используя координаты этих вершин, система рассчитывает карты теней от источников, что будет описано позднее.
Процесс задания геометрии для спрайта показан на Рис. 17. На первом шаге автоматически создаются четыре вершины (Рис. 17.1). После этого пользователь может добавлять и перемещать новые вершины (Рис. 17.2) до получения необходимого контура (Рис. 17.3).
Рис. 17 Формирование геометрии двухмерного объекта
5.2 Источники освещения
Помимо окружающего света, в данной работе реализованы четыре типа источников освещения: Точечный источник (Point Light), Направленный источник (Directional Light), Spot Light и Area Light.
Все типы источников освещения имеют общие атрибуты, представленные в
Таблица 1.
Таблица 1
Общие атрибуты всех типов источников освещения
Имя атрибута |
Тип |
Значение по умолчанию |
Модификатор доступа |
Отображение в инспекторе |
|
Color |
Color |
Color. white |
public |
Да |
|
Intensity |
float |
1 |
public |
Да |
|
Cookie |
Texture2D |
null |
public |
Да |
|
Type |
float |
1 |
protected |
Нет |
|
Shadow map |
Render texture |
null |
public |
Нет |
|
Shadow shader |
string |
"ShadowTexture" |
protected |
Нет |
|
Width |
int |
512 |
public |
Нет |
|
Height |
int |
512 |
public |
Нет |
|
Icon |
string |
"Light2D. png" |
protected |
Нет |
Атрибут Color определяет цвет излучаемого света, Intensity - его интенсивность. Cookie представляет собой текстуру, используемую в качестве маски для освещаемой области. Эти атрибуты единственные из общих, доступные для модификации пользователем в редакторе.
Type задает тип источника в числовом виде, в последствии это значение передается в качестве четвертой координаты позиции источника в шейдер для определения, какая функция расчета освещения должна быть использована. Shadow map - специальная текстура, имеющая ширину Width и высоту Height. Она используется для построения непосредственно карты теней источника. Строка Shadow shader хранит названия шейдера, используемого для наложения тектуры тени. Icon задает название изображения, используемого данным источником в качестве иконки в окне редактора Unity.
Точно так же у каждого источника должна быть собственная реализация некоторых методов. ShadowMap () формирует карту теней. MeterialSettings () отвечает за передачу необходимых данных об источнике в шейдер объекта. Функция IsInsideArea () проверяет, попадает ли данный объект в зону, освещенную источником, и, соответственно, надо ли его обрабатывать. Данные атрибуты и методы составляют абстрактный класс LightSourceScript. Это позволяет добавлять новые типы источников, не меняя логику работы менеджера освещения.
Также данный класс предоставляет метод OnDrawGizmos (), который идентичен у всех источников освещения. Он позволяет отобразить в окне редактора какую-либо графическую информацию о данном источнике. Так как интерфейс настройки атрибутов источников освещения реализуется в отдельных скриптах, здесь формируется только то, что не зависит от конкретного экземпляра класса. В данном методе реализуется только отображение соответствующей иконки в окне редактора на месте расположения источника.
Рассмотрим подробнее реализацию каждого типа источника.
5.2.1 Ambient Light
Ambient Light - единственный тип освещения, представляющий собой не отдельный класс, а параметр менеджера освещения. Атрибутом менеджера задается цвет окружающего освещения, который далее передается шейдерам всех объектов этого плана.
5.2.2 Point Light
Как описывалось ранее, Point light освещает все объекты в пределах определенного радиуса. Данный тип источника имеет значение type равное 1, а ширина и высота карты теней задается пользователем в зависимости от необходимой детализации. Уникальные атрибуты перечислены в
Таблица 2.
Таблица 2
Уникальные атрибуты класса Point Light
Имя атрибута |
Тип |
Значение по умолчанию |
Модификатор доступа |
Отображение в инспекторе |
|
Range |
float |
5 |
public |
Да |
Переменная Range задается пользователем и определяет радиус освещаемой области.
Рассмотрим реализацию методов этого класса.
5.2.2.1 ShadowMap
В первую очередь, при построении на карте тени рассматриваемого в данный момент объекта, координаты вершин заданной ему геометрии переносятся таким образом, чтобы источник освещения являлся началом координат. Как описывалось ранее, расчет теней происходит только для тех объектов, которые имеют соответствующий компонент, попадают в зону, освещаемую источником, и лежат с источником в одной плоскости. Так как разрабатываемая система подразумевает использование системы планов, использовать камеру для того, чтобы отрендерить в текстуру все объекты, освещаемые источником затруднительно. Поэтому информация об окружающих объектах поступает к источнику не в виде текстуры с отрисованными силуэтами, а в виде координат точек геометрии объектов. Рисование на карте теней производится при помощи низкоуровневой графической библиотеки Unity GL [15].
Построение карты теней точечного источника происходит в несколько этапов. Для каждого объекта, находящегося на одном уровне с источником, и имеющего компонент, задающий геометрию, формируется тень в результате следующих шагов:
1. Определение, находится ли источник внутри объекта
2. Поиск базовых и вспомогательных точек
3. Поиск крайних точек
4. Формирование четырехугольников
5. Поиск корректирующих коэффициентов для задания UV координат
6. Поиск "точек привязки"
7. Наложение текстуры тени
5.2.2.1.1 Определение, находится ли источник внутри объекта
В первую очередь, необходимо проверить, находится ли данный источник освещения внутри одного из объектов. В таком случае его карта теней будет представлять из себя полностью затененный участок.
Для данной проверки используется алгоритм определения вхождения точки в произвольный многоугольник, предложенный в [16]. Изначально метод был основан на расчете барицентрических координат точки (б, в, г), относительно треугольника V0V1V2, где V1 и V2 - две соседние вершины многоугольника, а V0 - произвольная точка. На основе знаков этих координат можно определить, находится точка внутри треугольника, снаружи, на одной из граней, соответствует ли вершине треугольника, лежит ли на одной прямой с какой-либо гранью. Полный перечень возможных комбинаций и соответствующих им положений точки представлен на Рис. 18.
Рис. 18 Соответствие знаков барицентрических координат точки и её положения относительно треугольника
Однако, если произвольную точку зафиксировать в координатах (x, y-1), где x и y - координаты рассматриваемой точки, то исключается возможность их совпадения, а алгоритм получает существенное упрощение. В первую очередь следует транслировать координаты рассматриваемых в данный момент вершин так, чтобы проверяемая точка находилась в центре координат (Рис. 19).
Рис. 19 Коррекция координат вершин исследуемого треугольника
В таком случае, процесс определения нахождения точки в произвольном многоугольнике заключается в поэтапном исключении определенных случаев, основанных на эвклидовых координатах точек.
Если в < 0 или г < 0, то точка находится вне треугольника (Рис. 20.1). Это соответствует случаю, когда грань ViVj не пересекает ось y, что подразумевает (xi > 0 and xj > 0) or (xi < 0 and xj < 0), или xi · xj > 0, где i и j - номера исследуемых вершин.
Рис. 20 1) Отрезок ViVj не пересекает ось ординат; 2) Точки Vi и Vj лежат ниже оси абсцисс
Проверяемая точка однозначно находится вне треугольника, y-координаты вершин которого меньше нуля (Рис. 20.2). Если xi > xj, следует проверить положение ViVj относительно точек P и O. Существует три варианта (случай, при котором ViVj проходит через P или O будет рассмотрен далее): ViVj находится выше P и O (Рис. 21), между P и O (Рис. 22.1), ниже P и O (Рис. 22.2). Первый случай удовлетворяет условию |OViVj| > 0 и |PViVj| > 0, второй - |OViVj| > 0 и |PViVj| < 0, третий - |OViVj| < 0 и |PViVj| <0. Таким образом, P находится внутри OViVj, если |PViVj| > 0 и xi > xj. Если |PViVj| < 0 и xi >xj, P находится вне треугольника независимо от знака |OViVj|.
Рис. 21 Отрезок ViVj лежит выше точек P и O
Рис. 22 1) Отрезок ViVj расположен между точками P и O; 2) Отрезок ViVj находится ниже точки O
Случай xi < xj, аналогичен предыдущему за исключением того, что Vi и Vj меняются местами. Если xi = xj, то треугольник OViVj является вырожденным. Тогда рассматриваются три случая: P находится на отрезке ViVj (Рис. 23.1 - 2), P ниже ViVj (Рис. 23.3) или P выше ViVj (Рис. 23.4). Последний случай был уже рассмотрен ранее. Точка P находится на отрезке ViVj тогда, когда (yi ? 0 или yj ? 0) и xi = xj.
Рис. 23 Взаимное расположение точки P и грани ViVj в вырожденном треугольнике
Существует три случая, при которых P принадлежит одной из граней треугольника (Рис. 24).
P лежит на ViVj (включая концы), если б = 0, это соответствует случаю |PViVj| = 0 и треугольник не был отброшен ранее.
P лежит на OVj (не включая вершины), если xj = 0 и треугольник не был отброшен ранее.
P лежит на OVi (не включая вершины), если xi = 0 и треугольник не был отброшен ранее.
Рис. 24 Точка P принадлежит одной из граней треугольника
Если O лежит на ViVj (включая вершины), OViVj - вырожденный треугольник. Разбором данного случая можно пренебречь, так как предыдущие условия (|PViVj| < 0 и xi < xj) и (|PViVj| > 0 и xi < xj) вернули корректный результат.
5.2.2.1.2 Поиск базовых и вспомогательных точек
Следующим шагом является поиск базовых точек для формирования меша тени. Такими точками являются те, отрезок к которым от источника освещения не пересекается ни с одной гранью. Для этого следует воспользоваться теоремой о том, что два отрезка пересекаются тогда и только тогда, когда концы каждого из них лежат по разные стороны прямой, которой принадлежит другой. Для определения положения точки относительно прямой можно воспользоваться векторным произведением векторов, сформированных двумя точками прямой и исследуемой точкой. Так как все точки лежат в одной плоскости, векторное произведение будет перпендикулярно этой плоскости, тогда нам нужно лишь узнать знак z-координаты, который укажет, куда этот вектор направлен. Таким образом, если знаки векторных произведений для двух точек совпадают, то они находятся по одну сторону от прямой. В результате, мы проверяем пересечение отрезков, концами одного из которых являются положение источника освещения и проверяемая вершина, а другого - две соседние вершины, образующие проверяемую грань. При нахождении первого пересечения, проверка заканчивается - точка базовой не является.
Координаты вспомогательных точек получаются путем переноса координат базовых в направлении вектора от источника к базовой точке.
5.2.2.1.3 Поиск крайних точек
Для построения меша итоговой тени требуется обходить найденные вершины в определенном порядке. Однако, в результате предыдущих действий мы получили лишь массив вершин. Требуется определить так называемые "крайние" точки, предполагающие, что все вершины, задающие форму тени, будут располагаться в секторе между ними.
Для этого используется функция поиска максимального угла между векторами, сформированными двумя соседними базовыми точками и положением источника. Так как в сформированном ранее массиве все вершины располагаются последовательно в порядке возрастания порядковых номеров, можно однозначно утверждать, что крайние точки будут располагаться в массиве либо в соседних ячейках, либо в двух крайних.
Метод Vector3. Angle () определяет меньший из углов между векторами. Однако, так как форма объекта может представлять собой невыпуклый многоугольник, следует учитывать, что угол может быть больше 180 градусов, соответственно, следует принимать значение угла, равное 360-Vector3. Angle (). Для нахождения таких случаев, проверяется пересечение отрезка с концами в точке расположения источника освещения и точки, лежащей на биссектрисе проверяемого игла, на предмет пересечения с гранями многоугольника. Если такого пересечения не наблюдается, то значение меньшего угла вычитается из 360 градусов.
Найдя максимальный угол, мы получаем две вершины, его образующие. Именно они и являются крайними точками.
5.2.2.1.4 Формирование четырехугольников
Когда получены необходимые координаты, можно построить меш тени. Для этого строятся четырехугольники, вершинами которых являются две базовые точки и соответствующие их вспомогательные. Так как в последствии необходимо на этот меш наложить текстуру тени, требуется для каждой вершины определить UV-координаты этой текстуры.
5.2.2.1.5 Поиск корректирующих коэффициентов для задания UV координат
UV-координаты определяют, какой точке накладываемой текстуры будет соответствовать данная вершина меша. Каждая координата имеет значение в промежутке (0;
1). Так точка (0, 0) соответствует нижнему-левому углу текстуры, а (1, 1), соответственно, верхнему-правому. Однако, если задать UV-координаты вершинам четырехугольника таким образом, на границе двух треугольников возникнет видимый шов.
Чтобы избежать этого, требуется передавать в вертексный шейдер три координаты (qu, qv, q), которые будут обратно преобразовываться в фрагментном шейдере делением на q [17].
Допустим, задан четырехугольник p0p1p2p3.
Тогда q вычисляется следующим образом. Введем вектора a, b и c. Они будут равны соответственно , , , тогда:
, , , , ,
В итоге, получается четыре значения q, тогда UV-координаты для каждой вершины будут представлены в виде , где i - номер вершины.
Данные координаты задаются при создании каждой новой вершины. Так как итоговый меш состоит из нескольких четырехугольников, необходимо умножать u-координату на некоторый коэффициент, определяющий какая часть текстуры соответствует этому полигону. Для того, чтобы найти этот коэффициент, предлагается вычислить угол между первой крайней точкой, соответствующей UV-координате (0, 0), и данной вершиной и разделить это значение на общий угол между крайними точками.
5.2.2.1.6 Поиск "точек привязки"
Так как вершины многоугольника соединяются прямой гранью, при определенных значениях угла между крайними точками может возникать ситуация, что сформированная фигура не заполняет карту целиком. Чтобы предотвратить это, формируются дополнительные треугольники между соседними вершинами и точкой привязки одного из них. Точкой привязки является ближайшая вершина четырехугольника карты тени.
5.2.2.1.7 Наложение текстуры тени
Сформировав итоговый меш тени, необходимо наложить на него соответствующую текстуру. Если у освещаемого объекта задана форма тени, выбирается она, в противном случае, данная текстура является полностью черным изображением. Для того, чтобы сформировать области затенения, текстура накладывается, используя простой мультипликативный шейдер, благодаря чему все точки затененные до этого, или находящиеся в тени в сформированной карте, остаются таковыми.
Подобные документы
Разработка компьютерной игры "Эволюция" с помощью игрового движка Unit. Сравнение критериев игры-аналога и разрабатываемой игры. Разработка графического интерфейса пользователя. Настройки камеры в редакторе Unity. Структура файла сохранения игры.
дипломная работа [3,6 M], добавлен 11.02.2017Разработка игрового "движка" с использованием языка C++ для написания кода, графического пакета DirectX9 для вывода графики. Использование физического "движка" PhysX для взаимодействия объектов. Технико-математическое описание задачи, листинг программы.
дипломная работа [4,5 M], добавлен 02.09.2013Разработка игрового проекта на игровом движке Unity 3D в среде программирования MS Visual Studio 2017. Блок-схема алгоритма работы приема сообщений с сервера на клиенте с упрощенным описанием выполняемых команд. Реализация пользовательского интерфейса.
курсовая работа [1,5 M], добавлен 10.07.2017Особливості Unity у створенні віртуального робочого середовища. Моделювання у віртуальному середовищі навчальних проектів у вигляді лабораторних робіт з фізики, які спрямовані на покращення і спрощення навчального та практичного процесу навчання.
курсовая работа [74,0 K], добавлен 30.08.2014Платформа Unity 3D как средство разработки компьютерных деловых игр. Рассмотрение реализации взаимодействия между подсистемой проведения деловых игр и модулем визуализации. Формирование игровых уровней на примере компьютерной игры "Проезд перекрестка".
дипломная работа [2,8 M], добавлен 22.08.2017Изучение существующих подходов к использованию компьютерных игр в образовательном процессе. Разработка и реализация проекта игрового обучающего приложения на мобильной платформе. Выбор платформы и средств реализации игрового обучающего приложения.
дипломная работа [3,4 M], добавлен 12.08.2017Игровые технологии; назначение, классификация и цель создания мобильных игр. Развлекательные, коммуникативные, терапевтические, диагностические функции игровой деятельности. Создание мобильного программного приложения "Angry Crane" в среде Java Android.
курсовая работа [1,5 M], добавлен 09.12.2014Общая характеристика игровых движков, история их создания и совершенствования, современное состояние и перспективы. Сущность и значение шейдерных эффектов, программирование данных программ. Механизм и этапы разработки 3D-приложения, его тестирование.
дипломная работа [2,2 M], добавлен 16.06.2011Исследование основных требований к пользовательскому интерфейсу. Краткая характеристика используемой операционной системы Windows 7 и языка программирования. Особенность создания удобного управления в игре. Главные требования к аппаратному обеспечению.
курсовая работа [453,0 K], добавлен 02.06.2017Разработка адресных и технических требований к игре. Написание сценария. Общая концепция разработки приложения. Разработка схем алгоритмов приложения. Игровые технологии. Выбор среды и программированного языка. Описание пользовательского интерфейса.
курсовая работа [1,6 M], добавлен 14.06.2014