Главная » Программирование игр под Android » Проверка пересечения ограничивающих сфер – РАЗРАБОТКА ИГР ДЛЯ ОС ANDROID

0

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

Рис. 11.13. Уменьшаем ограничивающую сферу для того, чтобы она лучше вписывалась в объект

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

Как же мы столкнем две сферы друг с другом? Говоря другими словами, как мы проверим, что сферы пересекаются? Это возможно определить точно так же, как и в случае с кругами. Все, что нам нужно, – измерить расстояние от центра одной сферы до центра другой сферы. Если оно меньше, чем сумма радиусов этих сфер – значит, эти сферы столкнулись. Создадим простой класс Sphere (листинг 11.14).

Листинг 11.14. Класс Sphere.java, простая ограничивающая сфера

Этот код точно такой же, что и в классе Circlе. Мы изменили лишь вектор, хранящий координаты центра. Теперь он является экземпляром класса Vector3, а не Vector2.

Расширим также класс OverlapTester методами, проверяющими пересечение двух сфер и наличие точки внутри сферы. Его код содержится в листинге 11.15.

Листинг 11.15. Фрагменты класса OverlapTester.Java, добавляем методы для тестирования сфер

Опять же этот код в точности повторяет аналогичный код класса Ci rcl е. Мы просто изменили тип центра сфер на Vector3.

ПРИМЕЧАНИЕ

Целые и посвящены определению столкновений трехмерных объектов. Если вы хотите окунуться в этот интересный мир, я предложу вам у Определение столкновений в реальном времени (Real-time Collision Detection), написанную Кристером Эриксоном (Christer Ericson) и выпущенную издательством Morgan Kaufmann в 2005 году. Она должна быть на книжной полке любого уважающего себя разработчика игр.

Классы GameObject3D и DynamicGameObjectSD

Теперь, когда мы определили ограничивающую фигуру для 3D -объектов, мы с легкостью можем написать эквиваленты классов GameObject и DynamicGameObject, использованных в 2D. Мы просто заменим все экземпляры класса Vector2 на экземпляры класса Vector3 и будем применять класс Sphere вместо класса Rectangle. В листинге 11.16 показан код класса Game0bject3D.

Листинг 11.16. Класс Game0bject3D. представление простого объекта, имеющего позицию и границы

Этот код очень тривиален, возможно, вам вообще не понадобится его объяснять. Единственный недостаток заключается в том, что нам приходится хранить одинаковую позицию дважды: один раз как член position класса GameObject3D и второй – внутри члена position экземпляра класса Sphere, содержащегося в классе GameOb ject3D. Это несколько неэлегантно, но для ясности мы будем придерживаться этого поведения.

Унаследовать класс DynamicGame0bject3D от этого класса довольно просто. Код представлен в листинге 11.17.

Листинг 11.17. Класс DynamicGame0bject3D.java, динамический аналог класса Game0bject3D

Опять же заменяем экземпляры класса Vector2 на экземпляры класса Vector3 и счастливо улыбаемся.

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

Подводя итог

Снова мы рассмотрели множество тайн из мира программирования игр. Мы немного поговорили о векторах в 3D, которые, как оказалось, так же просты, как и их собратья в 2D. Общая идея: мы просто добавили координату по оси z. Мы также рассмотрели освещение в OpenGL ES. Написали вспомогательные классы, необходимые для представления материалов и источников освещения, с их помощью довольно просто можно установить освещение на сцене. Для лучшей производительности и сокращения количества графических артефактов реализовали mip-текстурирование как часть класса Texture. Изучили реализацию простых камер с видом от первого и от третьего лица, написав совсем немного кода и воспользовавшись классом Matri х. Поскольку создание 3D -сетей вручную в коде утомительно, мы также рассмотрели один из наиболее простых и популярных форматов 3D -файлов: Wavefront OBJ. Мы снова рассмотрели старую физическую модель и перенесли ее в трехмерную реальность, это оказалось так же просто, как и создание 3D -векторов. Последним пунктом нашего плана была работа с ограничивающими фигурами и представлением объектов в 3D. Учитывая наши скромные потребности, мы выбрали очень простые решения для обеих проблем, которые практически идентичны тем, что мы использовали в 2D.

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

Источник: Mario Zechner / Марио Цехнер, «Программирование игр под Android», пер. Егор Сидорович, Евгений Зазноба, Издательство «Питер»

По теме:

  • Комментарии