Игровой движок для продуктов Apple на базе низкоуровневого графического API Metal 2

Размещено на http://www.allbest.ru/

ПРАВИТЕЛЬСТВО РОССИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ

ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ

НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ

«ВЫСШАЯ ШКОЛА ЭКОНОМИКИ»

Факультет компьютерных наук

Департамент программной инженерии

Выпускная квалификационная работа

на тему «Игровой движок для продуктов Apple на базе низкоуровневого графического API Metal 2».

Выполнил студент группы БПИ153

Кравцов М.Е.

Научный руководитель Доцент

Кандидат технических наук Брейман А.Д.

Москва 2019



Реферат

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

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

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

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

Ключевые слова: игровой проект, игровой движок, разработчик, библиотека, open-source.



Abstract

Game projects are of great importance for the modern world. It can be a high-quality game for a professional spoiled player, or it can be a developmental game for children of different ages. Games are needed not only to spend time, but also to pump up your skills, for example, you can develop fast reaction and decision making in real-time strategies, you can also develop communication skills in multiplayer games. You can pack a lot of interesting ideas into the game wrapper, there is even such a modern term “gamification”. Game approaches sympathize with people, and they are more likely to get involved in any process.

For the development of game projects are used so-called "Game Engine". At the same time, with the help of them you can create projects that are not directly related to games, for example, you can use the engine to create a project for interactive disassembly and assembly of the engine to make it easier for auto mechanics to learn without using this physical "object". Also, you can use the engine to create an augmented reality application in which you can place furniture around the house and see if it is suitable before you make a purchase.

Developers of game projects are very important to have on hand a tool for the rapid implementation of the game concept or the game itself. Developing your own engine is a lot of time and effort, and you shouldn't forget about the time to support it and edit bugs. You can order the development of a remote studio, but it is very expensive and there is no guarantee that your project will not be interested in your project, and it will cease to support it. The last option is to use ready-made game engines, it is much cheaper, both in time and in money.

This project is a ready-made solution in the form of a software library for a quick start and development of a game project. It implements an extensible library architecture, basic components for work, it is also posted on the Internet on GitHub as an open-source project, and therefore other developers can contribute to its development.

Keywords: game project, game engine, developer, library, open-source.

Основные определения термины и сокращения

1. API (application programming interface) - программный интерфейс, описывающий способы взаимодействия пользователя с программой.

2. Игровой движок (Game Engine) - базовое программное обеспечение компьютерной игры.

3. Процессор (CPU) - электронный блок, исполняющая машинные инструкции (код программ), главная часть аппаратного обеспечения компьютера.

4. Видеокарта (GPU) - отдельное устройство персонального компьютера, выполняющее графический рендеринг.

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

6. Скрипт (Script / Component) - наследник базового компонента движка, который имеет жизненный цикл.

7. Шейдер (Shader) - компьютерная программа, предназначенная для исполнения процессорами видеокарты (GPU).

8. Модель (Model) - объект в компьютерной графике.

9. Статическая библиотека (Static Library) - файл с исходным кодом или объектный файл, предназначенный для вставки в программу на этапе компоновки.

10. Линковка (Linking) - процесс во время компиляции или работы программы по поиску зависимостей в виде библиотек и фреймворков

11. Баг (Bug) - ошибка в программе или в системе, из-за которой программа выдает неожиданное поведение.

12. Краш (Crash) - неожиданное прекращение работы программы или системы

13. Нативная программа (Native Program) - это программа, которая была разработана для использования на определённой платформе или на определённом устройстве.



Содержание

• Реферат
• Abstract
• Основные определения термины и сокращения
• Введение
• 1. Обзор существующих игровых движков и их возможности
• 1.1 Существующие решения
• 1.1.1 Unreal Engine
• 1.1.2 Unity 3D
• 1.2 Необходимость разработки программного решения
• 2. Базовая работа движка
• 2.1 Инструменты и подготовка движка к внешнему использованию
• 2.2 Необходимые теоретические знания и применение их на практике
• 3. Архитектура
• 3.1 Введение
• 3.2 Граф сцены и компоненты
• Заключение
• Список источников
• 

Введение

Для начала нужно понять, что такое игровой движок и зачем он нужен. Игровой движок нужен для:

· отображения некоторого количества графических моделей на экране устройства

· взаимодействия между объектами (необязательно физическое)

· выполнения второстепенных процессов (например воспроизведения звука)

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

Главный компонент любого игрового движка - это низкоуровневое графическое API. В данной работе используется графический движок Metal, разработанный компанией Apple, для устройств, на базе macOS, iOS, tvOS.

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

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

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

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

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

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

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



1. Обзор существующих игровых движков и их возможности

1.1 Существующие решения

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

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

Буду рассматривать только бесплатные и условно бесплатные движки, так как мой проект будет полностью бесплатен и открыт для совместной работы

1.1.1 Unreal Engine

Игровой движок, разрабатываемый и поддерживаемый компанией Epic Games. Данный движок предлагает мощные инструменты для разработки. С 2015 года стал бесплатным, но разработчикам нужно платить 5% от каждой проданной копии игры. Совсем недавно он начал поддерживать Metal.

Достоинства:

· Поддерживает большинство известных платформ

· Написан на языке C++. Язык можно назвать нативным для операционных систем.

· Визуальный редактор с возможностью писать скрипты визуально

· Скрипты разрабатываются также на языке С++, что также очень эффективно по производительности

Недостатки:

· Исходный код движка недоступен для чтения и изменения

· Тяжеловесный, пустая сцена на iOS весит примерно 40 МБ

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

· Используется Metal первой версии

· Разработка на С++ требует большого порога вхождения. Возможны утечки памяти при неаккуратном обращении с переменными и без своевременного удаления объектов в кучи из памяти

· Шейдеры пишутся на языке HLSL. Нельзя прекомпилировать файлы шейдеров заранее

1.1.2 Unity 3D

Игровой движок, разрабатываемый и поддерживаемый компанией Unity Technologies. Движок условно бесплатный, разработчикам необходимо платить месячную подписку, если проект коммерческий. Подписка стоит 125 долларов в месяц (или 25, но с ограничениями). Я очень хорошо знаком с данным движком, даже были собственные игровые проекты, размещенные в AppStore (магазин приложений для платформы iOS). С недавних пор Unity также поддерживает Metal.

Достоинства:

· Поддерживает все популярные платформы

· Написан на С++ (некоторые части на C#)

· Скрипты необходимо писать на языке C#. Низкий порог вхождения

· Визуальный редактор сцены

· Визуальный редактор шейдеров

· Большое сообщество с готовыми ответами на большинство вопросов

· Удобная система компонентов и скриптов

Недостатки:

· Исходный код недоступен для чтения и изменения. Можно получить исходный код на индивидуальной основе крупным компаниям, стоит это порядка $100 000

· Тяжеловесный, пустая сцена на платформе iOS весит примерно 30 МБ

· C# очень популярный язык с низким порогом вхождения, но за это надо платить производительностью. Управления памятью происходит за счет системы Garbage Collector (Сборщик мусора), что накладывает дополнительную нагрузку на процессор

· Урезанная поддержка Metal.

1.2 Необходимость разработки программного решения

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

Важная составляющая движка - это то, на чем «клиентам» придется писать компоненты(скрипты), так как это и есть разработка конечного продукта. Языки в представленных движках C++ и C# имеют свои недостатки, описанные выше. Swift такой же быстрый по скорости работы как С++, при этом такой же удобный как C#. Это связано с тем, что языку всего 4 года, и его создавали с учетом современных требований разработки. Высокая скорость работы достигается за счет системы автоматического подсчета ссылок на объекты, лежащие в кучи, и своевременного удаления их при счетчике ссылок равным нулю. Эта система работает на этапе компилятора, а следовательно, не дает нагрузки в режиме runtime (во время работы приложения).

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

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

Исходя из вышенаписанного было принято решение разработать собственный игровой движок без использования сторонних библиотек.



2. Базовая работа движка

2.1 Инструменты и подготовка движка к внешнему использованию

В качестве инструментов разработки были выбраны следующие инструменты:

· Xcode - IDE (среда разработки под продукцию Apple)

· Swift 5 - Основной язык для движка

· Metal 2.1 - Низкоуровневое графическое API для устройств Apple

· Metal Shading Language - Язык для написания шейдеров под Metal. Основан на стандарте С++ 14 с рядом ограничений

· С - язык для определения общих структур между Swift сущностями и шейдерами

· Blender - ПО для создания моделей.obj формата

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

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

Решение - это создать статическую библиотеку, чтобы среде разработке не было необходимости собирать каждый раз заново собирать движок, а уже использовать прекомпилированный файл <libraryName>.a. Данная библиотека будет добавляться в исходный файл на стадии компиляции, что называется статической линковкой. Статическая линковка имеет ряд преимуществ над динамической, но также есть и недостатки. Динамическая линковка нужна тогда, когда нет необходимости при запуске приложения иметь слинкованной зависимости. В данном проекте библиотека движка всегда должна быть загружена в память при старте приложения, потому что в этом и суть движка, это основа приложения. Также файл шейдера формата «.metal» тоже прекомпилируется в файл «.metallib» и не требует компиляции каждый раз при сборки проекта.

Данный движок работает на всех поддерживаемых платформах Metal: macOS, iOS, tvOS. И для каждой платформы нужно собирать свою версию библиотеки, так как компилятор использует свои оптимизации для каждой платформы. В итоге получаем для каждой платформы два скомпилированных файла: один файл статической библиотеки, второй - файл библиотеки шейдеров.

Рисунок 6 Артифакты после компиляции библиотек (движка и шейдеров)

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

Рисунок 7 Структура Демо проекта



2.2 Необходимые теоретические знания и применение их на практике

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

Для того, чтобы отобразить хоть что-то на экране пользователя необходимо реализовать два шейдера: вершинный и пиксельный (vertex & fragment). Первый нужен для того, чтобы разместить вершину в экранных координатах, также именуемых как NDC (Normalized Device Coordinate).

Рисунок 8 Куб отрисовки NDC в API Metal

В API Metal NDC - это куб с координатами x [-1, 1], y [-1, 1], z [0, 1]. Чтобы получить конечную точку в данных координатах, необходимо сделать следующие преобразования:



Размещено на http://www.allbest.ru/

Рисунок 9 Получение конечного положение вершины в NDC

Так как преобразование матриц применяется справа налево, то в самом конце должен быть точка, которую нам необходимо преобразовать, затем идет матрица преобразования нашей модели, которая содержат в себе три преобразования (масштаб, поворот, перемещение). После этого необходимо добавить преобразование камеры или, проще говоря точки обзора. Так как при перемещении камеры она не двигается, а двигается весь «мир» вокруг неё, то необходимо взять матрицу модели камеры и инвертировать ее - в результате получим матрицу обзора. Завершающим этапом является преобразование матрицы проекции. Матрицы проекции обычно бывают двух типов: перспектива и ортогональность. Матрица перспективы будет отображать объекты с учетом их удаленности от камеры и перспективы. Это всем привычный вид нашего глаза. Другим типом матрицы проекции является ортогональная матрица. Данный тип подразумевает, что весь «свет» от объектов строго параллелен друг другу и не искажается. На выходе имеем «плоское» изображение без «глубины». Чаще всего используется для 2D игр и интерфейсе приложений.

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



Рисунок 12 Матрица перспективы. Реализация

Рисунок 13 Ортогональная матрица. Реализация

Матрица модели состоит из трех компонентов: матрицы масштаба, матрицы поворота и матрицы перемещения. Именно в такой последовательности, то есть перемножать их надо справа налево

Рисунок 14 Матрица модели

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



Рисунок 15 Матрица поворота ZYX

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

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

В данной структуре отсутствуют те минусы, что есть преобразованиях с использованием углов Эйлера. Операции над кватернионами очень легковесные и для них надо хранить всего 4 скаляра, в то время как для применения операций над углами Эйлера необходимо хранить матрицу 3х3, то есть 9 скаляров.

Итого, для того чтобы определить модель в пространстве необходимо получить матрицу вращения, матрицу масштаба и матрицу сдвига:

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

Можно задать константный цвет объекту, но тогда он будет выглядеть неестественно

Рисунок 23 Отрисовка с сплошным цветом объектов

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

Рисунок 24 Расчёт рассеиваемого освещения от объекта



Рисунок 25 Отрисовка только с рассеиваемым освещением

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

Рисунок 26 Расчёт фонового освещения



Рисунок 27 Отрисовка с рассеиваемым и фоновым светом

Теперь неосвещенные участки модели не полностью темные, а имеют фоновое освещение.

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

Рисунок 28 Расчёт зеркального освещения

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



Рисунок 29 Отрисовка с рассеивемым, фоновым и зеркальным освещением

Это необходимый минимум для того, чтобы реализовать освещение сцены.

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



3. Архитектура

3.1 Введение

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

Рассмотрев конкурентов и применив свой опыт разработки программных продуктов в компании ПАО Сбербанк, было решено разработать компонентно-ориентированную архитектуру игрового движка. Подробнее про данную архитектуру будет написано ниже. Яркий представитель данной архитектуры в мире игровых движков - Unity 3D.

Повторюсь про стек разработки:

· macOS 10.14 и выше

· Xcode 10 и выше

· Swift 5 и выше

Начнём с запуска движка, рассмотрев первый запускаемый файл исполнения main.swift

Рисунок 30 Запуск движка с параметрами

При старте приложения запускается движок и настраиваются необходимые параметры запуска. В данном случае используется паттерн Builder. Он хорошо знаком всем разработчикам.

Далее создается окно приложения для каждой платформы своё macOS / iOS / tvOS. В окне создается так называемый view controller, который отлавливает взаимодействие с пользователем, а уже в нем создается окно отрисовки. В окне отрисовки и происходит вывод буфера видеокарты на экран.

Не будем в данном случае рассматривать настройки пайплайна отрисовки и загрузки библиотеки шейдеров

3.2 Граф сцены и компоненты

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

Пример структура сцены:

Рисунок 31 Пример структуры сцены в логах консоли



Рисунок 32 Схематичный пример сцены

Рисунок 33 Диаграма клссов графа сцены

Рассмотрим граф сцены подробнее. Сцена всегда содержит один корневой объект с именем Root. Каждый объект может содержать в себе неограниченное количество дочерних объектов. Каждый объект также содержит неограниченное количество компонентов. У сцены, объекта и компонента есть жизненный цикл, который включает в себя уведомление о начале работы, обновлении кадра со значением времени между кадрами deltaTime, а также уведомление о исчезновении со сцены.

Разберемся в компоненте подробнее, так как они и задают поведение объектам. Каждый объект содержит минимум один компонент - Transform. Данный компонент задает положение объекта на сцене (сдвиг, поворот, масштаб). Камера на самом деле тоже компонент, который содержит в себе матрицу обзора и матрицу проекции.

Рисунок 34 Кусок кода компонента камеры

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

Чтобы объект мог быть отрисован, он должен содержать в себе компонент модели ModelComponent.

Рисунок 35 Инициализация компонента модели

Рисунок 36 Код отрисовки компонента

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

Рисунок 37 Структура вершины, обрабатываемая видеокартой

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

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

Рисунок 38 Пример реализации компонента, который двигает объект по прямой

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

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



Рисунок 39 Пример компонента камеры "от первого лица"

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



Заключение

Можно подвести итог и сказать, что проделана большая работа по изучению работы игровых движков и изучению нового низкоуровневого API Metal 2 специально разработанного компанией Apple для своих устройств и операционных систем macOS, iOS, tvOS. Metal активно развивается и имеет ряд оптимизаций на уровне платформы, что дает ему преимущество над другими низкоуровневыми API.

Стоит заметить, что архитектура движка продумана на основе существующих решений и лучших практик. За основу взята компонентно-ориентированная архитектура.

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

В репозитории на GitHub лежит проект движка, а также демо-проект с примером использования: https://github.com/kravtsovguy/GameEngine-Metal



Список источников

1. Metal [Электронный ресурс]. URL: https://developer.apple.com/metal/ (дата обращения: 01.02.2019).

2. Unreal Engine [Электронный ресурс]. URL: https://www.unrealengine.com (дата обращения: 01.02.2019).

3. Unity 3D [Электронный ресурс]. URL: https://unity.com/ (дата обращения: 01.02.2019).

4. LearnOpenGL. Трансформации. [Электронный ресурс]. URL: https://habr.com/ru/post/319144/ (дата обращения: 01.02.2019).

5. Metal Kit. [Электронный ресурс]. URL: http://metalkit.org (дата обращения: 01.02.2019).

6. iOS static library. [Электронный ресурс]. URL: https://medium.com/@imsantoshk/ios-static-library-7c62bb984e6 (дата обращения: 01.02.2019).

7. The Perspective and Orthographic Projection Matrix. [Электронный ресурс]. URL: https://www.scratchapixel.com/lessons/3d-basic-rendering/perspective-and-orthographic-projection-matrix/orthographic-projection-matrix (дата обращения: 01.02.2019).

8. GCC Manual - 6.36 Specifying Attributes of Variables. [Электронный ресурс]. URL: https://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html (дата обращения: 01.02.2019).

9. FreeSound. [Электронный ресурс]. URL: https://freesound.org/ (дата обращения: 01.02.2019).

10. Blender. [Электронный ресурс]. URL: https://www.blender.org (дата обращения: 01.02.2019).

11. 3D Graphics with Metal. [Электронный ресурс]. URL: https://www.raywenderlich.com (дата обращения: 01.02.2019).

12. Metal by Tutorials. [Электронный ресурс]. URL: https://store.raywenderlich.com/products/metal-by-tutorials (дата обращения: 01.02.2019).

13. Каверзные кватернионы. [Электронный ресурс]. URL: https://habr.com/ru/post/183908/ (дата обращения: 01.02.2019).

14. Avoiding Gimbal Lock. [Электронный ресурс]. URL: https://answers.unity.com/questions/573035/avoiding-gimbal-lock.html (дата обращения: 01.02.2019).

15. Xcode & cross-platform frameworks. [Электронный ресурс]. URL: http://ilya.puchka.me/xcode-cross-platform-frameworks/ (дата обращения: 01.02.2019).

Размещено на Allbest.ru

...