Игровой движок Unity
Обзор аналогов игрового движка Unity: 2D Light System, 2D Dynamic Lights and Shadows, Light2D - GPU Lighting System, Light2D, 2DVLS (2D Volumetric Lights and Shadows) и Seasons After Fall Rendering System. Игровой движок Ethanon. Система освещения Unity.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | курсовая работа |
Язык | русский |
Дата добавления | 09.09.2016 |
Размер файла | 58,2 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Введение
Игровой движок Unity очень популярен среди разработчиков видеоигр, особенно среди начинающих, из-за простоты освоения и бесплатности. Несмотря на то, что движок ориентирован на трехмерные приложения, он поддерживает работу с двухмерной графикой. Однако не все компоненты редактора одинаково хорошо работают в 3D и 2D. В частности, встроенная система освещения не позволяет двухмерным объектам служить полноценным препятствием для света и отбрасывать тени на другие объекты.
Ко всем объектам прикреплен одинаковый материал с одинаковым шейдером. Если куб является полноценным препятствием для света, то четырехугольник отбрасывает тень только от тех источников, которые не лежат в одной плоскости с ним, а спрайт и вовсе игнорируется системой расчета теней. В трехмерном пространстве это обусловлено физическим расчетом освещаемых областей, так как четырехугольник, в отличие от куба, не имеет толщины, однако в двухмерном пространстве объемные фигуры представлены плоскими 2D объектами, поэтому необходимо обеспечить возможность взаимодействия со светом двухмерных объектов, идентичную взаимодействию трехмерных в 3D пространстве.
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.
К сожалению, большинство вышеупомянутых систем требуют покупки для их использования. Поэтому, обзор функционала некоторых из них выполнялся на основе комментариев пользователей, видео-демонстраций и тестовых сцен. игровой движок 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. Плановость предполагает разделение сцены на слои, подобно планам, например, в живописи: задний план, средний план, передний план.
Естественно количество планов на сцене не должно ограничиваться тремя, так разработчики Swing Swing Submarine используют следующее разделение: background 2, background 1, playground foreground [10] .
Основная идея реализации планов заключается в том, что каждый из них имеет собственное, независимое освещение. Так источники одного плана никак не взаимодействуют с объектами другого. Это верно не только для источников, размещаемых непосредственно на сцене, но и для значения окружающего света (Ambient Light). Итоговая сцена формируется последовательным наложением планов друг на друга.
Несмотря на то, что это можно было бы частично моделировать расположением групп объектов на большом расстоянии по оси z друг от друга, такой метод реализации не поддерживал бы различные настройки Ambient Light и Directional Light в разных слайсах.
Внутри одного плана тоже необходимо каким-либо образом определять глубину. Для этого можно использовать несколько параметров, реализованных в Unity: порядок прорисовки объекта в слое и значение z-координаты объекта. Так как многие объекты в сцене представлены несколькими спрайтами, и для правильного их отображения требуется определить порядок их прорисовки, то использовать параметр порядка в слое затруднительно. Однако, Unity изначально является трехмерным движком, и даже в двухмерном режиме у нас есть возможность распределять объекты вдоль оси z.
Предлагается следующая модель взаимодействия света с объектами, в зависимости от их взаимного расположения по оси z. Объект, находящийся над источником света (ближе к камере), не освещается им и не отбрасывает теней. Объект под источником также не отбрасывает теней, но освещается. Объект, находящийся на одном уровне с источником (имеющий то же значение координаты z), не освещается, но является препятствием для прохождения света, отбрасывая тень на все, что находится за ним.
4.2 Объекты
Двухмерные объекты в Unity можно разделить на два типа по классу их компонента-рендерера (указан в скобках).
- Спрайты (SpriteRenderer);
- Полигоны (MeshRenderer), то есть quad и plane.
В зависимости от задач разрабатываемого приложения, могут использоваться объекты любой из групп, поэтому необходимо обеспечить работу разрабатываемой системы с обоими типами. Предполагается, что у объектов задан некоторый материал, к которому прикреплен соответствующий шейдер, отвечающий за расчет внутреннего освещения компонента.
Так как двухмерный объект представлен на сцене четырехугольной фигурой с наложенной на неё текстурой, определение формы освещаемого изображения на основе координат четырех вершин приведет к появлению неточностей в формировании области затенения. Таким образом, необходимо опираться либо на значение альфа-канала текстуры, либо на заданную отдельно геометрию объекта. Так как предполагается, что в разрабатываемой системе будет возможность задать форму тени, а для этого требуется знать координаты вершин, определяющих тень, о чем будет описано далее, был выбран второй вариант.
4.3 Источники света
Освещение любого объекта зависит от источников света, расположенных на сцене. По аналогии с системой освещения Unity можно выделить следующие типы источников.
Ambient Light
Ambient light симулирует освещение, полученное за счет многократного отражения света от поверхностей окружающих объектов. Технически, Ambient light освещает все точки сцены с одинаковой интенсивностью и как правило является константой. В разрабатываемой системе данный источник освещения задается индивидуально для каждого плана.
Основным параметром Ambient Light является цвет.
Directional Light
Directional light излучает свет в виде бесконечного множества бесконечно удаленных от объектов и направленных под определенным углом лучей. Как правило, Directional Light используется для моделирования солнечного света. Данный тип источника не имеет позиции в пространстве, радиуса действия, и интенсивность освещения не падает с удалением объекта от источника.
Основными параметрами Directional Light являются угол поворота, цвет и интенсивность.
Point Light
Point light излучает свет одинаково во всех направлениях из определенной точки пространства. Интенсивность света падает с удалением от этой точки. Данный источник используется для моделирования света от ламп, костров и подобных ненаправленных источников.
Основными параметрами Point Light являются позиция, радиус, цвет и интенсивность.
Spot Light
Spot light очень похож на Point light. Отличие заключается в том, что в данном источнике освещения есть приоритетное направление излучения света. То есть, если освещаемую область point light можно представить в виде сферы (круга в 2D пространстве), то spot light освещает только некоторый заданный сектор. Этот тип может моделировать свет фонаря, прожектора и других направленных источников.
Основными параметрами Spot Light являются позиция, угол поворота, радиус, угол освещаемого сектора, цвет и интенсивность [12].
Area Light
В отличие от ранее описанных типов источников, Area Light излучает свет равномерно по определенной площади. Поэтому у освещенных объектов появляются области как полной тени, так и полутеней. Расчет освещения от такого источника - достаточно ресурсоемкая задача, из-за этого принимаются различные упрощения, как например расчет нескольких теней с их последующим размытием [13]. С точки зрения расчетов, интенсивность света затухает подобно Point light по мере удаления от области, освещаемой источником.
В данной работе, предполагается, что Area Light освещает некоторую область равномерно, подобно Directional Light, направленному параллельно лучу наблюдения. Таким образом, основными параметрами данного источника будут цвет, интенсивность, позиция, а также длина и ширина освещаемой площади.
Emissive Objects
Некоторые поверхности сами по себе представляют источники освещения. Это значит, что их освещенность всегда максимальна, независимо от наличия рядом других источников. Для достижения данного эффекта применяются специальные шейдеры [13]. В данной работе подобный тип освещения не рассматривается.
Кроме позиции, цвета и интенсивности, все источники освещения имеют еще один общий атрибут - Cookie. Он представляет собой черно-белую текстуру, задающую уровень освещенности в конкретной точке. Так, если точке в пространстве соответствует белая область Cookie, она освещается полностью, если черная, находится в тени, независимо от того, действительно ли попадает эта точка в тень от какого-то объекта. Такая маска позволяет задавать источники нестандартной формы, или тени от объектов, неотображаемых на сцене.
4.4 Система расчета теней
Одним из самых важных элементов системы освещения является система расчета теней. Существует два типа теней:
- Hard-edged (жесткие тени)
- Soft-edged (мягкие тени)
Мягкие тени состоят из двух регионов: полутень и полная тень. Полная тень представляет собой неосвещенные регионы, в то время как полутень отображает частично затененные области. Жесткие тени включают в себя только полные тени [13].
Так как в работе будут представлены точечные источники освещения, то будут рассмотрены только жесткие тени.
Дополнительно, в 2D пространстве тени можно классифицировать на внешние и внутренние. Под внешними подразумеваются затененные области на других объектах, находящихся в тени от рассматриваемого. Внутренние - те тени, которые объект отбрасывает сам на себя. Так как двухмерные объекты по определению являются плоскими фигурами, второй класс теней реализуется шейдерами при помощи дополнительных карт, задающих рельеф объекта.
Расчет внешних теней
Существует два основных способа формирования теней от источника [12]:
- При помощи Shadow Maps
- Используя Stencil Shadows
Карты теней (Shadow Maps) получаются за счет пофрагментного теста глубины из точки видимости камеры. Сначала, сцена рендерится из зоны видимости источника освещения, и полученные результаты записываются в буфер глубины. После это, сцена отображается как обычно, но по сгенерированной на предыдущем этапе карте определяется, находится ли данный пиксель в тени или нет.
Для каждого вертекса каждого треугольника считается его позиция в относительно источника света. Если этот фрагмент располагается дальше, чем соответствующий ему фрагмент карты теней, то он находится в тени [13].
Так как эта техника основана не на геометрии объектов, а на их отображении, она может быть использована для работы с объектами, имеющими альфа-канал [12].
Stencil Shadows (или Shadow Volumes) - техника, формирующая области, затененные отбрасывающими тени объектами. Она позволяет отображать высоко детализированные тени, качество которых зависит только от полигонального представления объектов [12]. Силуэт объекта, отбрасывающего тень, как бы вытягивается в сторону от источника света. Иными словами, на основе видимой источником геометрии объекта формируется объем, точки внутри которого находятся в тени.
Первый метод подходит и для работы в двухмерном пространстве, однако он не позволяет определять непосредственно точки, формирующие область тени объекта. Используя эти точки можно было бы задавать тени определенную форму.
Второй способ требует наличия полигонов у обрабатываемых объектов. Однако, 2D спрайты состоят из двух треугольников, чего не достаточно для формирования теней не четырехугольных фигур. Так как у пользователей нет доступа к потоку передачи информации в шейдеры Unity, и получить данные о сцене из шейдера не представляется возможным, то расчеты затененных областей приходится производить заранее. Таким образом, необходимо сформировать карту теней одним из двух методов:
- При помощи трассировки лучей;
- При помощи детализации геометрии объекта.
Метод трассировки лучей
При помощи трассировки лучей, можно искать переходы от пустых областей к объектам и наоборот (Рис. 10.1 - 10.5) и запоминать эти точки. После этого, для каждого объекта формируется четырехугольник, у которого две вершины имеют координаты найденных на предыдущем шаге точек, а две расположены таким образом, чтобы лежать на одной прямой с соответствующей точкой из первых и центром текстуры.
Однако данная технология работает достаточно эффективно только, если объекты представлены выпуклыми многоугольниками, и на одном спрайте расположен только один объект. В противном случае, алгоритм сформирует тени, которые не будут соответствовать действительности.
Для того, чтобы избежать подобной ситуации, предлагается использовать вышеописанный алгоритм для нахождения точек начала и конца затененных областей, но расчет теней внутри производить непосредственно методом трассировки лучей. Для этого из каждой точки найденного ранее сектора, следует пустить луч по направлению к источнику освещения. Если этот луч пересечет какой-либо объект, это будет значить, что точка находится в тени. В противном случае, ничего не загораживает точку от источника, и, соответственно, она считается освещенной.
Использование трассировки лучей для каждого пикселя изначально возможно, однако это добавляет определенное количество лишних вычислений. Кроме того, определяемые алгоритмом точки необходимы для формирования теней заданной формы.
Метод детализации геометрии объекта
Несмотря на то, что 2D объекты не имеют как таковой геометрии, можно, определив края объектов, создать несколько ключевых точек, которые будут заменять в алгоритме расчета теней вершины трехмерных моделей.. Проводя лучи от источника освещения к этим точкам, можно по наличию пересечения с контуром какого-либо объекта судить, находится ли эта точка в тени. После этого, останется только построить тень, используя точки для формирования полигонов.
Форма теней
Так как в двухмерном пространстве зритель смотрит на сцену преимущественно под одним углом, может возникнуть ситуация, при которой будет практически невозможно однозначно сказать, какую форму имеет объект. Несколько трехмерных объектов могут иметь одинаковую по форме проекцию на плоскость камеры.
Для того, чтобы получить тень заданной текстурой формы требуется знать четыре точки, по которым будет сформирован меш. Предполагается, что эти точки будут получены в результате работы алгоритма предыдущего шага. На полученный полигон накладывается текстура тени.
Внутреннее освещение
Освещение самих объектов вычисляется шейдерами, прикрепленными к ним.
Шейдеры должны, получая параметры необходимых источников, обеспечивать освещение объектов. Формула расчета освещенности зависит от выбранной модели.
Предполагается, что функции расчета освещения в разных моделях, использования карт нормалей и др. будут описаны в специальном 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. Выделенные точки можно переносить тем же образом, что и стандартные объекты на сцене. Таким образом, создавая и располагая вершины, пользователь системы может задавать контуры освещаемого объекта. Если есть необходимость получить специальный эффект, необязательно делать контур идентичным действительной границе изображения. Используя координаты этих вершин, система рассчитывает карты теней от источников, что будет описано позднее.
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(), который идентичен у всех источников освещения. Он позволяет отобразить в окне редактора какую-либо графическую информацию о данном источнике. Так как интерфейс настройки атрибутов источников освещения реализуется в отдельных скриптах, здесь формируется только то, что не зависит от конкретного экземпляра класса. В данном методе реализуется только отображение соответствующей иконки в окне редактора на месте расположения источника.
Рассмотрим подробнее реализацию каждого типа источника.
Ambient Light
Ambient Light - единственный тип освещения, представляющий собой не отдельный класс, а параметр менеджера освещения. Атрибутом менеджера задается цвет окружающего освещения, который далее передается шейдерам всех объектов этого плана.
Point Light
Как описывалось ранее, Point light освещает все объекты в пределах определенного радиуса. Данный тип источника имеет значение type равное 1, а ширина и высота карты теней задается пользователем в зависимости от необходимой детализации. Уникальные атрибуты перечислены в Таблица 2.
Таблица 2. Уникальные атрибуты класса Point Light
Имя атрибута |
Тип |
Значение по умолчанию |
Модификатор доступа |
Отображение инспекторе |
|
Range |
float |
5 |
public |
Да |
Переменная Range задается пользователем и определяет радиус освещаемой области.
Рассмотрим реализацию методов этого класса.
ShadowMap
В первую очередь, при построении на карте тени рассматриваемого в данный момент объекта, координаты вершин заданной ему геометрии переносятся таким образом, чтобы источник освещения являлся началом координат. Как описывалось ранее, расчет теней происходит только для тех объектов, которые имеют соответствующий компонент, попадают в зону, освещаемую источником, и лежат с источником в одной плоскости. Так как разрабатываемая система подразумевает использование системы планов, использовать камеру для того, чтобы отрендерить в текстуру все объекты, освещаемые источником затруднительно. Поэтому информация об окружающих объектах поступает к источнику не в виде текстуры с отрисованными силуэтами, а в виде координат точек геометрии объектов. Рисование на карте теней производится при помощи низкоуровневой графической библиотеки Unity GL [15].
Построение карты теней точечного источника происходит в несколько этапов. Для каждого объекта, находящегося на одном уровне с источником, и имеющего компонент, задающий геометрию, формируется тень в результате следующих шагов:
1. Определение, находится ли источник внутри объекта
2. Поиск базовых и вспомогательных точек
3. Поиск крайних точек
4. Формирование четырехугольников
5. Поиск корректирующих коэффициентов для задания UV координат
6. Поиск «точек привязки»
7. Наложение текстуры тени
Определение, находится ли источник внутри объекта
В первую очередь, необходимо проверить, находится ли данный источник освещения внутри одного из объектов. В таком случае его карта теней будет представлять из себя полностью затененный участок.
Для данной проверки используется алгоритм определения вхождения точки в произвольный многоугольник, предложенный в [16]. Изначально метод был основан на расчете барицентрических координат точки (б, в, г), относительно треугольника V0V1V2, где V1 и V2 - две соседние вершины многоугольника, а V0 - произвольная точка. На основе знаков этих координат можно определить, находится точка внутри треугольника, снаружи, на одной из граней, соответствует ли вершине треугольника, лежит ли на одной прямой с какой-либо гранью.
Однако, если произвольную точку зафиксировать в координатах (x, y-1), где x и y - координаты рассматриваемой точки, то исключается возможность их совпадения, а алгоритм получает существенное упрощение. В первую очередь следует транслировать координаты рассматриваемых в данный момент вершин так, чтобы проверяемая точка находилась в центре координат.
В таком случае, процесс определения нахождения точки в произвольном многоугольнике заключается в поэтапном исключении определенных случаев, основанных на эвклидовых координатах точек.
Если в < 0 или г < 0, то точка находится вне треугольника. Это соответствует случаю, когда грань ViVj не пересекает ось y, что подразумевает (xi > 0 and xj > 0) or (xi < 0 and xj < 0), или xi · xj > 0, где i и j - номера исследуемых вершин.
Проверяемая точка однозначно находится вне треугольника, y-координаты вершин которого меньше нуля.
Если xi > xj, следует проверить положение ViVj относительно точек P и O. Существует три варианта (случай, при котором ViVj проходит через P или O будет рассмотрен далее): ViVj находится выше P и O (Рис. 21), между P и O ниже P и O. Первый случай удовлетворяет условию |OViVj| > 0 и |PViVj| > 0, второй - |OViVj| > 0 и |PViVj| < 0, третий - |OViVj| < 0 и |PViVj| <0. Таким образом, P находится внутри OViVj , если |PViVj| > 0 и xi > xj. Если |PViVj| < 0 и xi >xj, P находится вне треугольника независимо от знака |OViVj|.
Случай xi < xj, аналогичен предыдущему за исключением того, что Vi и Vj меняются местами.
P лежит на ViVj (включая концы), если б = 0, это соответствует случаю |PViVj| = 0 и треугольник не был отброшен ранее.
P лежит на OVj (не включая вершины), если xj = 0 и треугольник не был отброшен ранее.
P лежит на OVi (не включая вершины), если xi = 0 и треугольник не был отброшен ранее.
Если O лежит на ViVj (включая вершины), OViVj - вырожденный треугольник. Разбором данного случая можно пренебречь, так как предыдущие условия (|PViVj| < 0 и xi < xj) и (|PViVj| > 0 и xi < xj ) вернули корректный результат.
Поиск базовых и вспомогательных точек
Следующим шагом является поиск базовых точек для формирования меша тени. Такими точками являются те, отрезок к которым от источника освещения не пересекается ни с одной гранью. Для этого следует воспользоваться теоремой о том, что два отрезка пересекаются тогда и только тогда, когда концы каждого из них лежат по разные стороны прямой, которой принадлежит другой. Для определения положения точки относительно прямой можно воспользоваться векторным произведением векторов, сформированных двумя точками прямой и исследуемой точкой. Так как все точки лежат в одной плоскости, векторное произведение будет перпендикулярно этой плоскости, тогда нам нужно лишь узнать знак z-координаты, который укажет, куда этот вектор направлен. Таким образом, если знаки векторных произведений для двух точек совпадают, то они находятся по одну сторону от прямой. В результате, мы проверяем пересечение отрезков, концами одного из которых являются положение источника освещения и проверяемая вершина, а другого - две соседние вершины, образующие проверяемую грань. При нахождении первого пересечения, проверка заканчивается - точка базовой не является.
Координаты вспомогательных точек получаются путем переноса координат базовых в направлении вектора от источника к базовой точке.
Поиск крайних точек
Для построения меша итоговой тени требуется обходить найденные вершины в определенном порядке. Однако, в результате предыдущих действий мы получили лишь массив вершин. Требуется определить так называемые "крайние" точки, предполагающие, что все вершины, задающие форму тени, будут располагаться в секторе между ними.
Для этого используется функция поиска максимального угла между векторами, сформированными двумя соседними базовыми точками и положением источника. Так как в сформированном ранее массиве все вершины располагаются последовательно в порядке возрастания порядковых номеров, можно однозначно утверждать, что крайние точки будут располагаться в массиве либо в соседних ячейках, либо в двух крайних.
Метод Vector3.Angle() определяет меньший из углов между векторами. Однако, так как форма объекта может представлять собой невыпуклый многоугольник, следует учитывать, что угол может быть больше 180 градусов, соответственно, следует принимать значение угла, равное 360-Vector3.Angle(). Для нахождения таких случаев, проверяется пересечение отрезка с концами в точке расположения источника освещения и точки, лежащей на биссектрисе проверяемого игла, на предмет пересечения с гранями многоугольника. Если такого пересечения не наблюдается, то значение меньшего угла вычитается из 360 градусов.
Найдя максимальный угол, мы получаем две вершины, его образующие. Именно они и являются крайними точками.
Формирование четырехугольников
Когда получены необходимые координаты, можно построить меш тени. Для этого строятся четырехугольники, вершинами которых являются две базовые точки и соответствующие их вспомогательные. Так как в последствии необходимо на этот меш наложить текстуру тени, требуется для каждой вершины определить UV-координаты этой текстуры.
Поиск корректирующих коэффициентов для задания UV координат
UV-координаты определяют, какой точке накладываемой текстуры будет соответствовать данная вершина меша. Каждая координата имеет значение в промежутке (0; 1). Так точка (0, 0) соответствует нижнему-левому углу текстуры, а (1, 1), соответственно, верхнему-правому. Однако, если задать UV-координаты вершинам четырехугольника таким образом, на границе двух треугольников возникнет видимый шов.
Чтобы избежать этого, требуется передавать в вертексный шейдер три координаты (qu, qv, q), которые будут обратно преобразовываться в фрагментном шейдере делением на q [17].
В итоге, получается четыре значения q, тогда UV-координаты для каждой вершины будут представлены в виде , где i - номер вершины.
Данные координаты задаются при создании каждой новой вершины. Так как итоговый меш состоит из нескольких четырехугольников, необходимо умножать u-координату на некоторый коэффициент, определяющий какая часть текстуры соответствует этому полигону. Для того, чтобы найти этот коэффициент, предлагается вычислить угол между первой крайней точкой, соответствующей UV-координате (0, 0), и данной вершиной и разделить это значение на общий угол между крайними точками.
Поиск «точек привязки»
Так как вершины многоугольника соединяются прямой гранью, при определенных значениях угла между крайними точками может возникать ситуация, что сформированная фигура не заполняет карту целиком. Чтобы предотвратить это, формируются дополнительные треугольники между соседними вершинами и точкой привязки одного из них. Точкой привязки является ближайшая вершина четырехугольника карты тени.
Наложение текстуры тени
Сформировав итоговый меш тени, необходимо наложить на него соответствующую текстуру. Если у освещаемого объекта задана форма тени, выбирается она, в противном случае, данная текстура является полностью черным изображением. Для того, чтобы сформировать области затенения, текстура накладывается, используя простой мультипликативный шейдер, благодаря чему все точки затененные до этого, или находящиеся в тени в сформированной карте, остаются таковыми.
MaterialSettings
Данный метод позволяет передать в шейдер объекта ту информацию об источнике, которая является уникальной для данного типа. В случае Point Light это позиция источника и его тип, радиус, матрицы трансформации для cookie и карты теней, текстура cookie.
Позиция источника передается в виде четырех координат, первые три из которых соответствуют положению источника на сцене, а последняя определяет его тип. Радиус источника передается в виде числа с плавающей запятой.
Матрица трансформации cookie является перемножением трёх матриц: переноса, поворота и масштабирования. Стандартная функция SetTRS() перемножает матрицы в порядке "перенос, поворот, масштабирование", что не подходит для данного случая, так как поворот осуществляется относительно нуля координат. Из-за этого каждая матрица создаётся отдельно и после этого перемножается с другими таким образом, чтобы сначала повернуть объект, и лишь потом перенести и масштабировать. Матрица трансформации карты теней использует те же компоненты, но итоговая матрица не умножается на матрицу поворота.
Матрица трансформации карты теней получается перемножением матриц переноса и масштабирования, так как не зависит от вращения источника освещения.
IsInsideArea
Данный метод позволяет исключить некоторые объекты, неосвещаемые данным источником, из расчета карты теней. Объект считается освещенным Point Light, если хотя бы одна из вершин его фигуры находится на меньшем расстоянии от источника, чем радиус.
Spot Light
Класс Spot Light наследуется от Point Light. С точки зрения расчетов освещения этот тип источника освещения отличается от точечного только тем, что освещает объекты, расположенные в пределах конкретного сектора, заданного углом. Если угол равен 360 градусам, то Spot Light полностью идентичен Point Light.
Рассмотрим только те методы, которые отличаются от родительского класса.
ShadowMap
Весь алгоритм расчета теней остается неизменным, за исключением метода очистки карты теней. Если перед формированием карты в Point Light текстура полностью заливалась белым цветов, то здесь вся часть изображения, не попадающая в освещаемый сектор, заполняется черным. Для этого формируются неосвещенные треугольники из точки центра карты, соответствующей положению источника, точек, вектор к которым образует с вектором, направленным вертикально вниз угол, равный половине сопряженного угла заданному, и углов текстуры.
IsInsideArea
Помимо проверки нахождения как минимум одной из точек объекта внутри радиуса источника, метод определяет, попадает ли данная точка в освещаемый сектор. Это верно тогда, когда угол между вектором, образованными проверяемой точкой и положением источника и осью симметрии меньше значения половины угла, заданного параметром Spot Light.
Directional Light
Directional light моделирует источник освещения, удаленный на бесконечное расстояние от объекта, свет которого распространяется равномерно вдоль бесконечного числа лучей, направленных под заданным углом. Дополнительных атрибутов этот источник не имеет, так как угол поворота, как и положение в пространстве, задается компонентом Transform, прикрепленным ко всем объектам на сцене. Directional light имеет значение type, равное 0, а ширина и высота карты теней соответствуют габаритам области видимости камеры.
ShadowMap
Общий алгоритм построения карты теней Directional Light похож на Point Light. Однако, в данном случае нет необходимости проверять нахождение источника внутри объекта. Кроме того, перенос вспомогательных точек осуществляется вдоль вектора, направленного под углом, заданным источником. Таким образом, точки переносятся параллельно друг другу.
MaterialSettings
Набор передаваемых значений данным типом источника существенно меньше набора Point Light. В шейдеры передается лишь информация о позиции источника в пространстве (требуется для определения, располагается объект ниже, выше или на одном уровне с источником и матрица трансформации карты теней.
IsInsideArea
Directional Light освещает всю область сцены. Поэтому проверка заключается в определении, находится ли данный объект в видимой камерой области.
Area Light
В данной работе Area Light представляет собой равномерно освещенную область, заданную прямоугольником. Свет направлен параллельно взгляду наблюдателя, соответственно, данный тип источника не формирует тени объектов. Значение переменной type для Area light равно 2.
ShadowMap
Так как объекты, освещенные Area Light, не отбрасывают тени, то карта теней представляет собой белую текстуру 1x1 пиксель.
MaterialSettings
Area Light кроме общих атрибутов также передает в шейдер значения ширины и высоты освещаемой области.
IsInsideArea
Объект считается обрабатываемым Area Light, если хотя бы одна его вершина находится внутри образованного источником прямоугольника. Таким образом, необходимо проверить, что разность координат x данной точки и положения источника меньше половины заданной ширины, а разность координат y, соответственно, высоты. Тем не менее, данный метод используется для предотвращения обработки лишних объектов в ShadowMap(), и, учитывая, что Area Light не формирует теней, таким образом его реализация может быть сведена к возврату константного значения true.
5.3 Плановость
Для реализации системы планов используется встроенная в Unity система наследования. Для всех объектов, принадлежащих данному плану, он является родителем в иерархии Unity. Таким образом, возможно использовать встроенные функции, чтобы получить их количество и список.
Каждому объекту-плану прикрепляется скрипт менеджера освещения. Сначала этот компонент собирает информацию об источниках и освещаемых объектах этого плана. Для этого при помощи встроенной функции Unity в два массива записываются все компоненты Renderer и LightSource, прикрепленные к объектам-наследникам. После этого каждый кадр менеджер передает шейдерам всех объектов информацию об Ambient Light. Далее для каждого освещаемого объекта выбираются ближайшие восемь источников освещения. Для каждого из этих источников вызывается метод MaterialSettings, описанный ранее, который передает все необходимые параметры материалу. Затем в шейдер передаются параметры, наличие которых не зависит от реализации источника. Ими являются цвет, интенсивность и карта теней. Последняя перед этим формируется вызовом соответствующего метода источника.
5.4 Шейдер
Шейдеры Unity получают информацию об источниках света, например, об их положении или цвете, через встроенные переменные, объявленные в специальных cginc-файлах. К сожалению, значения в эти переменные записываются специальным потоком, доступа к которому у пользователей нет. При этом, изменять значения этих переменных так же не представляется возможным. Поэтому для работы с созданными в данной работе источниками потребуется описать необходимые переменные отдельно и передавать значения вручную из скрипта менеджера. Более того, несмотря на то, что язык Cg поддерживает работу с массивами, на данный момент функция передачи переменной из скрипта в какую-нибудь ячейку этого массива отсутствует. Равно как невозможно передавать обычному шейдеру целую структуру. Соответственно, необходимо объявить несколько экземпляров переменных подобного типа, отличающихся лишь порядковым номером. Для того, чтобы не приходилось при создании нового шейдера заново объявлять этот набор данных, их описание вынесено в отдельный cginc файл. Список и описание переменных приведено в Таблица 3.
...Подобные документы
Игровой движок Unity, его использование для создания приложений, связанных с архитектурой, обучением, визуализацией данных и электронными книгами. Разработка системы освещения для работы с двухмерными объектами в виде расширения редактора Unity.
дипломная работа [2,5 M], добавлен 11.02.2017Разработка игрового "движка" с использованием языка C++ для написания кода, графического пакета DirectX9 для вывода графики. Использование физического "движка" PhysX для взаимодействия объектов. Технико-математическое описание задачи, листинг программы.
дипломная работа [4,5 M], добавлен 02.09.2013Разработка компьютерной игры "Эволюция" с помощью игрового движка Unit. Сравнение критериев игры-аналога и разрабатываемой игры. Разработка графического интерфейса пользователя. Настройки камеры в редакторе Unity. Структура файла сохранения игры.
дипломная работа [3,6 M], добавлен 11.02.2017Разработка игрового проекта на игровом движке Unity 3D в среде программирования MS Visual Studio 2017. Блок-схема алгоритма работы приема сообщений с сервера на клиенте с упрощенным описанием выполняемых команд. Реализация пользовательского интерфейса.
курсовая работа [1,5 M], добавлен 10.07.2017Игровые технологии; назначение, классификация и цель создания мобильных игр. Развлекательные, коммуникативные, терапевтические, диагностические функции игровой деятельности. Создание мобильного программного приложения "Angry Crane" в среде Java Android.
курсовая работа [1,5 M], добавлен 09.12.2014Особливості Unity у створенні віртуального робочого середовища. Моделювання у віртуальному середовищі навчальних проектів у вигляді лабораторних робіт з фізики, які спрямовані на покращення і спрощення навчального та практичного процесу навчання.
курсовая работа [74,0 K], добавлен 30.08.2014Платформа Unity 3D как средство разработки компьютерных деловых игр. Рассмотрение реализации взаимодействия между подсистемой проведения деловых игр и модулем визуализации. Формирование игровых уровней на примере компьютерной игры "Проезд перекрестка".
дипломная работа [2,8 M], добавлен 22.08.2017Общая характеристика игровых движков, история их создания и совершенствования, современное состояние и перспективы. Сущность и значение шейдерных эффектов, программирование данных программ. Механизм и этапы разработки 3D-приложения, его тестирование.
дипломная работа [2,2 M], добавлен 16.06.2011История Network File System. Общие опции экспорта иерархий каталогов. Описание протокола NFS при монтировании удаленного каталога. Монтирование файловой системы Network Files System командой mount. Конфигурации, обмен данными между клиентом и сервером.
курсовая работа [1,3 M], добавлен 16.06.2014Изучение существующих подходов к использованию компьютерных игр в образовательном процессе. Разработка и реализация проекта игрового обучающего приложения на мобильной платформе. Выбор платформы и средств реализации игрового обучающего приложения.
дипломная работа [3,4 M], добавлен 12.08.2017Развитие Internet и новых способов общения между людьми. Система управления сайтом Content Manager System. Процесс создания, редактирования и оформления сайтов. Возможность создания различных по правам доступа частей сайта. Критерии выбора CMS.
реферат [35,5 K], добавлен 03.04.2011Модель релейной системы регулирования и идентификации структуры отдельного характерного элемента ЭКС зубца Р в системе MatLab. Анализ линейных звеньев с применением Control System Toolbox и Simulink. Методы построения переходных и частотных характеристик.
дипломная работа [1,1 M], добавлен 28.01.2015Overview history of company and structure of organization. Characterization of complex tasks and necessity of automation. Database specifications and system security. The calculation of economic efficiency of the project. Safety measures during work.
дипломная работа [1009,6 K], добавлен 09.03.2015Разработка информационной системы Dentist control system для работы стоматологической клиники - ведения записей о клиентах и врачах. Использование средства автоматизированной разработки приложений Borland C++ Builder 6.0 для работы с базой данных.
курсовая работа [2,3 M], добавлен 29.12.2012Изменение пользовательского интерфейса приложения Microsoft Office system 2007. Увеличение функциональности приложений для поддержки совместной работы (Office Word 2007, Office Excel 2007, Office PowerPoint 2007, Office Access 2007 и Office Outlook 2007).
контрольная работа [1,5 M], добавлен 13.12.2009Program game "Tic-tac-toe" with multiplayer system on visual basic. Text of source code for program functions. View of main interface. There are functions for entering a Players name and Game Name, keep local copy of player, graiting message in chat.
лабораторная работа [592,2 K], добавлен 05.07.2009Общая характеристика приложения Microsoft Office system 2007. Особенности форматов Microsoft Office Open XML. Технологии управления миграцией на новую версию. Возможности приложений Office Word, Excel, Access и Office PowerPoint 2007, их интеграция.
реферат [1,0 M], добавлен 13.09.2011Обзор системного и прикладного программного обеспечения используемого в ООО "Игровые системы". Описание компьютерной сети предприятия. Разработка игрового продукта для планшетов Apple iPad. Реализация визуального интерфейса и алгоритма работы модуля.
отчет по практике [1,4 M], добавлен 18.01.2015Разработка адресных и технических требований к игре. Написание сценария. Общая концепция разработки приложения. Разработка схем алгоритмов приложения. Игровые технологии. Выбор среды и программированного языка. Описание пользовательского интерфейса.
курсовая работа [1,6 M], добавлен 14.06.2014Исследование основных требований к пользовательскому интерфейсу. Краткая характеристика используемой операционной системы Windows 7 и языка программирования. Особенность создания удобного управления в игре. Главные требования к аппаратному обеспечению.
курсовая работа [453,0 K], добавлен 02.06.2017