Набор средств разработки 3D-игр

Game industry is growing with each passing year, with hundreds of games with years of development and multi-million dollar budgets released every year. This paper goes over the development of a 3D game development toolkit. Two distinct parts of a game development software can be distinguished - a scene editor and a program to load and play the created scenes.

During the development of each part of the software multiple problems are encountered, such as player interaction with objects on the scenes, 3d model control according to user input and game logic, level rendering in real time and developing the architecture of storing all resources.

As a result of the development a program for creating game scenes with 3D models and scripts was created, as well a program that allows playing created scenes. OpenGL and Qt frameworks were used for interface and scene rendering.

Aside from the process of creating all necessary data structures needed for the correct work of the program this paper describes the overview of some of the solutions implemented in this toolkit.

The paper contains 50 pages, 3 chapters, 36 illustrations, 4 appendices.

Keywords: Gamed, 3D, OpenGL, Development

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

Оглавление

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

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

Целью данной работы является разработка двух модулей: модуль создания трехмерных сцен и модуль воспроизведения созданных сцен.

Задачами выпускной квалификационной работы является:

1) Изучить предметную область.

2) Проанализировать существующие решения данной задачи.

3) Изучить технологию исполнения стороннего кода (скриптов Lua) при исполнении программы.

4) Освоить работу с OpenGL для рендеринга изображений в реальном времени.

5) Разработать структур данных игровых ресурсов, а также алгоритмов взаимодействия с ними.

6) Разработать архитектуру модуля редактирования сцен

7) Разработать и протестировать модуль редактирования сцен

8) Разработать архитектуру модуля для загрузки и исполнения действий, установленных на сцене.

9) Разработать и протестировать модуль загрузки и исполнения сцен

10) Оформить техническую документацию.

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

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

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

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

Глава 1. Обзор предметной области и анализ существующих решений

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

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

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

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

Пример использования глобальных данных сцене приведен на рис. 5, где изображена одна из сцен игры "Metal Gear Solid" (https://en.wikipedia.org/wiki/Metal_Gear_Solid). В данной игре игрок принимает на себя роль разведчика, проникающего в базу врага. В случае, если игрока заметят охранники - поднимется тревога, в течение которой охранники базы будут искать игрока. Это поведение обозначено красной табличкой "Alert" с таймером до окончания тревоги. Таким образом изменяется состояние всех врагов на сцене в зависимости от действий игрока. Для воссоздания такого поведения предлагается использовать данные сцены, в которых каждый из объектов сцены способен обновлять данные и тем самым оповещать другие объекты о каком-либо действии.

2.2 Алгоритмы

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

Управление моделью при помощи мышки

Во время создания трехмерной сцены разработчику необходимо расположить трехмерные объекты на сцене, а также иметь возможность перемещать объекты. Наиболее желаемой является возможность управлять положением объекта в пространстве при помощи мышки. Однако мышка перемещается по двухмерному пространству экрана, в то время как объекты сцены находятся в трехмерном пространстве. Существует два основных алгоритма, позволяющих решить эту задачу: Ray Casting и Color Picking.

Алгоритм Ray Casting

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

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

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

Рисунок 9 - Проекция трехмерного пространства в видимое

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

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

Алгоритм Color Picking

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

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

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

Для кодирования используются 3 значения цвета, используемого для отрисовки объекта - R (Red, красный цвет), G (Green, зеленый цвет) и B (Blue, синий цвет). Каждый из данных цветов принимает значение от 0 до 255. Соответственно различные комбинации данных полей используются для кодирования объекта, за исключением цвета (0, 0, 0), который используется для кодирования пустоты.

На рис. 12 представлена реализация алгоритма Color Picking. Объект ObjectPicker с именем picker используется для инициализации буфера отрисовки, и при вызове метода start изменяет текущий буфер отрисовки на собственный (вместо экрана). После окончания отрисовки (вызова метода render) требуется переключить режим отрисовки обратно на экран (метод stop()). Далее извлекается массив из трех значений unsigned int - это описанные выше значения RGB пикселя. При помощи этих значений можно получить объект, который был выбран мышкой (метод сцены chooseEntity).

Проекция положения мышки на положение выбранного объекта

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

Для определения новой координаты модели в трехмерном пространстве используются алгоритм "Ray Casting", однако вместо проверки на пересечение с моделью проверяется пересечение луча с плоскостью перемещения. Точка пересечения является новой точкой, которая должна совпадать с центром координат модели.

При расчете луча необходимо получить координаты нажатия мышки и "депроецировать" их в координаты пространства (раздел 2.2.1.1., рис. 13) при помощи матрицы обозрения и матрицы проекции. Данные матрицы принадлежат объекту Camera и получаются при помощи методов getViewMtr и getProjectionMatrix. Таким образом вектор луча, пущенного при помощи мышки, будет разностью координат нажатия мышкой ближней и дальней плоскости (mouseClickNear - mouseClickFar).

На рис. 14 представлен алгоритм, рассчитывающий новые координаты объекта. При помощи интерфейса указывается одна из плоскостей перемещения, которая задается тремя точками (plane.A, plane.B и plane.C). Эти точки проецирутся так, чтобы плоскость, пересечение с которой необходимо найти, проходила через центр координат тела, необходимого переместить. Далее находится точка пересечения луча и плоскости - эта точка является новой координатой центра координат тела [6].

Трансформация объекта

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

Редактор: Абсолютная трансформация

Абсолютная трансформация назначает объекту конкретно заданные параметры - координаты в пространстве, поворот, масштаб. Абсолютные изменения положения в пространстве используется при назначении объекту положение в пространстве мышкой (см. пункт 2.2.1.3). Абсолютные трансформации используются при работе с моделью в редакторе сцен.

Воспроизведение: Относительная трансформация

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

Обработка взаимодействия объектов друг с другом

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

2.3 Априорный и апостериорный расчёт коллизий

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

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

Апостериорная проверка устраняет столкновения объектов путем абсолютного изменения положения объекта в пространстве, после чего применяется сила отталкивания.

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

Охватывающая фигура

Как уже упоминалось в пункте 2.2.1.1. - рассчитывать столкновения с объектом напрямую - крайне трудоемкая задача. Однако в отличие от алгоритма "Ray Casting" для обработки столкновений объектов необходимо проверять попарно все полигоны, что значительно повышает трудоемкость задачи. Поэтому вводят в рассмотрение охватывающие фигуры ("Bounding Shape") [3].

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

При создании охватываюзей фигуры используется алгоритм AABB (Axis-Aligned Bounding Box, "Параллельная осям координат охватывающая коробка"). При расчете охватывающей фигуры сохраняются минимальные и максимальные координаты x, y, и z точек модели. На основании этих координат создается "коробка", полностью охватывающая трехмерную модель. Ребра данной фигуры параллельны осям координат.

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

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

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

Проверка на близость с объектом

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

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

Реализация этого алгоритма приведена на рис. 20 - объекты попарно сравниваются друг с другом на предмет чрезмерной "близости". Эта "близость" определена значением rad структуры охватывающего параллелепипеда, получаемого методом getBox. В случае, если объекты находятся слишком близко друг к другу - они добавляются в список пересчета столкновений.

"Острова" объектов

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

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

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

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

На рис. 22 показан алгоритм создания "острова" из набора объектов objects. При создании "острова" объектов каждый остров считается единым, глобальным объектом, где так же, как и у обычного объекта есть центр и дозволенный радиус приближения объекта к острову, где центр острова рассчитывается как среднее всех центров объектов, а радиус - это сумма расстояния от центра острова до самого дальнего объекта и радиуса самого дальнего объекта. Однако в отличие от расчета соприкосновения объектов при приближении объекта к острову он регистрируется в острове, после чего рассчитываются новые параметры острова. Аналогично и при удалении объекта из острова. Данные алгоритмы продемонстрированы на рис. 23.

Выводы по главе

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

Глава 3. Технические особенности реализации

Одна из основных требуемых функций редактора сцен и программы воспроизведения сцен - это рендеринг трехмерных объектов и сцен на экране. Реализация этого функционала доступна при помощи библиотек OpenGL и Direct3D, а также набора библиотек-"оберток" над ними. Для реализации была выбрана библиотека OpenGL, поскольку она является кросcплатформенной, и при этом является самой низкоуровневой библиотекой для прямого управления действиями видеокарты (рендеринг объектов). Было принято решение не использовать сторонние библиотеки, упрощающие работу с OpenGL, для более тонкой настройки рендеринга сцен.

Qt

Поскольку OpenGL не поддерживает создание окон в оконном сервере операционной системы, возникает потребность использовать дополнительные библиотеки, обеспечивающие связь OpenGL с оконным интерфейсом. Аналогично требуется поддерживать пользовательский ввод данных с клавиатуры или же при помощи мышки. Существует множество библиотек, обеспечивающих связку OpenGL с оконным интерфейсом операционной системы (GLFW, http://www.glfw.org/, GLUT, https://www.opengl.org/resources/libraries/glut/, SDL, https://www.libsdl.org/)

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

Один из видов виджетов, предоставляемых фреймворком Qt, является QOpenGLWidget - это виджет, в котором может отрисовываться изображение при помощи библиотеки OpenGL. Qt инициализирует контекст OpenGL при инициализации этого виджета, предоставляя интерфейс вызова всех доступных функций библиотеки OpenGL.

Вторая причина выбора Qt - это набор инструментов, предоставляемых разработчику при работе с OpenGL.

При отрисовке трехмерного объекта необходимо использовать математическую библиотеку, поддерживающую работу с векторами и матрицами. Каждая из трехмерных моделей, передаваемая на отрисовку в OpenGL, является набором точек в трехмерном пространстве. Изменение положения трехмерной модели в пространстве организуется при помощи матриц трансформации, несущих информацию об изменении положения точек в пространстве. Эти матрицы создается при помощи программы, исполняющейся на CPU, после чего передается на GPU (при помощи OpenGL)[1] вместе с точками-вершинами полигонов, которые необходимо нарисовать. Существует множество математических библиотек, реализующих операции с векторами и матрицами (glm, sb7-math), однако Qt имеет собственную реализацию данных операций как часть фреймворка.

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

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

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

Assimp

Существует множество различных видов упаковки и хранения трехмерных моделей. Так, например, формат Wavefront OBJ является текстовым форматом, при использовании которого в файле последовательно хранятся вершины полигонов модели, нормали и координаты текстур вершин, а также сами полигоны. Однако большинство форматов являются бинарными и требуют реализации алгоритма извлечения данных модели из файла. Существует множество различных библиотек для распаковки файлов 3D моделей (OpenSceneGraph, http://www.openscenegraph.org, ObjLoader, http://www.kixor.net/dev/objloader/, COLLADA, https://www.khronos.org/collada/). При реализации данной программы была использована библиотека Assimp (http://www.assimp.org/) из-за большого набора поддерживаемых форматов загрузки трехмерных объектов по сравнению с остальными.

3.2 Функционирование программы

В данном разделе описывается функционал основного инструмента для создания трехмерных игр - редактор сцен. Приводится описание основных элементов интерфейса и их использования, а также скриншоты разработанной программы. Данная программа была разработана для 64-битной операционной системы Mac OS X версии не ниже 10.10. Скриншоты представляют интерфейс разработанного приложения, исполняемого при запуске приложения GCUEditor.app.

Редактор: Управление сценами

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

Редактор: Управление объектами на сцене

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

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