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

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

Snapshots of the Universe – удивительное приложение для iOS, не так давно выпущенное самим Стивеном Хокингом совместно с компанией Random House . Приложение состоит из восьми экспериментов, которые дают пользователям возможность не только получить базовые знания по физике, но и познакомиться с принципами, управляющими нашей Вселенной. В рамках предложенных экспериментов игроки могут отправлять ракеты в открытый космос, собирать собственные звёздные системы, искать и изучать чёрные дыры. Каждый эксперимент можно проводить бесчисленное количество раз, изменяя физические параметры и наблюдая за появляющимися эффектами. Чтобы лучше понять эксперименты, можно зайти в раздел объяснения результатов и посмотреть видео. Приложение доступно на iTunes . Cтоимость игры от великого физика составляет всего лишь $4,99.

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

Игра от первого лица, разработанная лабораторией игр (MIT), даёт возможность игрокам познакомиться с восприятием пространства на околосветовых скоростях и понять теорию относительности. Задача игрока – перемещаться по 3D-пространству, собирать сферические объекты, которые замедляют скорость света на фиксированные значения, что даёт возможность наблюдать за различными визуальными эффектами эйнштейновской теории.

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

Crayon Physics Deluxe - это 2D-пазл/игра «в песочнице», которая даёт возможность испытать игрокам, что было бы, если бы их рисунки могли превращаться в реальные физические объекты. Задача игрока – помогать шарику собирать звёздочки, рисуя подходящие для его движения поверхности – мосты, переправы, рычаги и т.д. Всё происходит в волшебном мире детского рисунка, где инструментами игрока являются восковые карандашики. Как минимум игра развивает художественное видение и творческие способности, как максимум – позволяет познакомиться с основами механики - гравитацией, ускорением и трением. Для теста на сайте представлена демо-версия , полную версию для PC, Mac и Linux можно приобрести за $19,95, приложения на Android и iOS обойдутся в $2,99.

Впрочем, для тех, кто только приступил к изучению движения тел и различных физических сил, будет также интересно ознакомиться с образовательной видеоигрой Physics Playground. Игра представляет собой площадку, на которой игроку нужно выполнять достаточно простые действия – с помощью зелёного шара сбивать красный воздушный шарик. Вот тут-то и начинается классическая механика: без правильного применения законов Ньютона игрокам вряд ли удастся сконструировать в интерактивной среде механизмы, которые помогут привести в движение шарик. Впрочем, можно пользоваться и интуицией – главное, что на протяжении 80-ти уровней интуитивные знания, позволяющие достигать цели, постепенно приводят к пониманию закономерностей, которые лежат в основе классической механики. Игра разработана компанией Empirical Game , которая занимается созданием развивающих образовательных игр. В открытом доступе её, к сожалению, нет, однако разработчики предлагают связаться с ними, если вас заинтересовал этот продукт. В полной версии можно отслеживать успехи игроков с помощью анализа журналов лог-файла.

«Наука, индустрия развлечений и игра слились в красивом уникальном творческом опыте Newton’s Playground. Манипулируйте Вселенной, создавайте невероятные сочетания планет и запускайте гравитацию», - говорят создатели приложения. Newton’s Playground – интерактивное приложение, которое базируется на моделях, отражающих гравитационную взаимосвязь различных тел. Имитируя гравитационные отношения планет, небольшое приложение Newton’s Playground даёт своим игрокам возможность понаблюдать за взаимодействием сфер, плавающих в открытом пространстве, или же самому поэкспериментировать с массой и плотностью различных тел и создать собственную Солнечную систему. Все расчёты основаны на исследованиях института астрономии Sverre Aarseth"s. Стоимость приложения в App Store – $1,99.

«Algodoo создает новую синергию между наукой и искусством», - гласит надпись на одной из страниц игры. Algodoo – это уникальная платформа 2D-моделирования физических экспериментов от Algoryx Simulation AB . С помощью мультяшных образов и интерактивных инструментов Algodoo позволяет создавать удивительные изобретения, разрабатывать игры для использования в классе или специальные эксперименты для лабораторных занятий по физике. В процессе своих естествоиспытаний и создания различных механизмов участники игры могут использовать жидкости, пружины, шарниры, двигатели, световые лучи, различные индикаторы, оптику и линзы. Моделируя различные конструкции и меняя параметры, игроки изучают трение, преломление, силу тяжести и т.д. Для новичков на сайте представлено подробное руководство , а также создан канал Youtube , на котором можно посмотреть десятки видео по теме. Для Windows и Mac доступны бесплатные версии игры, приложение для iPad стоит $4,99.

Autodesk ForceEffect – приложение для инженеров, которые занимаются различного рода проектированием. С помощью Autodesk ForceEffect можно делать инженерные расчёты прямо на мобильном устройстве. Это существенно облегчает работу по дизайну на стадии создания концепции, так как мгновенно определяет жизнеспособность конструкции. Впрочем, приложение будет интересно и тем, кто хотел бы узнать, как различные силы влияют на объекты. Таким энтузиастам вместо схемы дома для эксперимента можно взять обычный велосипед и на основе его фото провести ряд экспериментов, которые покажут, какую нагрузку он способен выдержать и что влияет на равновесие велосипеда. Особенно приятно, что приложение находится в открытом доступе и бесплатно доступно для Android , iOS .

Лев Симонов aka LEVel

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

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

Что мы имеем

Довольно логично начать повествование с описания существующих моделей, вот только есть тут одно "но": подробное описание любой из них напрашивается не просто на отдельную статью, а на целый ряд статей или докторскую диссертацию. Так что придется ограничиться поверхностным упоминанием и такой же поверхностной оценкой. Итак, для начала надо вспомнить игру Half-Life 2, надеюсь, воспоминания о ней еще не преданы забвению. Мне, например, на ум сразу же приходят всяческие хитроумные головоломки, построенные на основных физических законах. Ну и, естественно, легендарная гравипушка, позволяющая испытать на прочность (реалистичность) местную физику. К чему я это все говорю? Очень просто. Это наглядно показывает возможности (кстати говоря, не все) одного из лучших игровых физических движков - Havok"а, который часто используется при создании игр высшего класса. Из примеров использования можно также упомянуть Max Payne 2, который тоже на физику не жаловался. Но в глубине монстра с названием Havok бьется сердце, называемое ODE (Open Dynamic Engine). ODE - еще один движок, гораздо менее проработанный, но зато бесплатный и "опенсорсный" ("open source" - с открытыми ресурсами), т.е. любой может бесплатно скачать себе его исходный код и изменить, как ему захочется. Именно так, например, поступили разработчики XPand Rally. Помимо этих двух наиболее ярких представителей семейства физических движков существует и множество других, менее ярких. Тут можно вспомнить Tokamak, Novodex и Newton Dynamics. Это также достаточно известные реализации, обладающие, правда, меньшими возможностями, да и их исходники всем подряд не дают. Вот примерно такая вырисовывается картина. Ну и справедливости ради надо сказать, что существует также целая армия маленьких самописных движков, написанных независимыми программистами для конкретных игрушек. Или просто для удовольствия.

И как оно работает?

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

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

Теперь поделим на части методы моделирования (взаимодействия?) твердых тел. Тут существует два основных метода: импульсная модель и модель, основанная на ограничениях. Импульсная модель наиболее проста, здесь надо только найти столкновения объектов (впрочем, это приходится делать в каждом методе) и приложить к ним силы, высчитанные по закону сохранения импульса. Такой метод очень удобен, если между телами нет каких-нибудь связей, хотя и их тоже можно реализовать на импульсах, правда, не совсем точно и правильно. Поэтому для систем, содержащих множество связей различной сложности, был придуман другой метод - ограничения. Метод, построенный на ограничениях, - это пример системного подхода к моделированию физики. Все соединения и контакты описываются математически как ограничения и добавляются в общую систему уравнений. Решив эту систему, мы получим новое состояние для каждого тела. Этот метод удобен в первую очередь тем, что с его помощью можно создавать любые ограничения. Эти возможности получили наибольшее применение в технологии Rag Doll.

Куклы

Замысловатое словосочетание Rag Doll переводится на русский язык как "тряпичная кукла". Итак, чтобы было понятней, начнем наше беглое описание данной сравнительно новой технологии сразу с практической части. Если мысленно перенестись в не очень далекое прошлое (примерно в 2000 год), то можно вспомнить, что в большинстве шутеров тела поверженных врагов (или монстров) лежат очень неестественно: они погружаются по пояс то в стену, то в дверь, то они повиснут над лестницей, как будто лежат на невидимых столах... Но вернемся в наши дни. Подавляющее большинство современных шутеров показывают гибель вражеских солдат очень реалистично: бедняги прислоняются к ближайшим стенам или картинно скатываются с лестниц. Почему? Потому что используют технологию Rag Doll.

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

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

Железо

Несложно догадаться, что все эти радости требуют затраты огромных ресурсов памяти и процессора. А ведь в современных компьютерных играх помимо физики надо рассчитывать просто горы информации: графика (хотя она почти полностью лежит на видеокарте, но все-таки затраты производительности CPU требуются немалые), искусственный интеллект, интерфейс и многое другое. Но при повышении реалистичности физики повышаются и требования к компьютеру, т.е. все более и более сложные физические модели требуют от системы все больше ресурсов. Что же делать? Когда-то давно подобная проблема возникла в области графики. Тогда судьбу центрального процессора облегчили, добавив принципиально новое устройство - 3D-ускоритель, процессор которого (GPU) взял на себя значительную часть вычислений, связанных с расчетами в области построения 3D-картинки. Теперь похожая ситуация повторяется и с физикой. Поэтому, для того чтобы снять с CPU обязанность рассчитывать медленную физику, в ближайшем будущем планируется повсеместное введение физического процессора (PPU - Physic Processor Unit). Первые реализации уже появились, но они еще не очень распространены, да и игр с их поддержкой совсем немного. Но все-таки эта технология рано или поздно приобретет ничуть не меньшее признание, чем аппаратное ускорение трехмерной графики. Первое "физическое ядро", разработанное сравнительно молодой компанией Ageia, называется PhysX. По заявлениям разработчиков, сделанным на конференции GDC (Game Developers Conference - конференция разработчиков игр), он позволяет честно смоделировать в реальном времени систему из 50 000 тел (это против 10-50 тел современными программными способами!) без особых потерь в скорости выполнения программы.

Взгляд в будущее

Итак, что же ждет нас в будущем? В этом вопросе я соглашусь с человеком, чье имя знакомо каждому разработчику игр и некоторым продвинутым геймерам - Джоном Кармаком (John Carmack). На конференции разработчиков игр GDC-2004 он сказал: "...d будущих поколениях игр появится моделирование погоды, моделирование жидкостей, моделирование пылевых облаков, переносимых ветром и огибающих окружающую среду". Сейчас мощности среднего персонального компьютера недостаточно для правильного моделирования таких сложных систем в реальном времени, тем более в компьютерных играх, но в будущем такое станет возможным. Это принесет еще больше реалистичности в компьютерные игры. С введением и развитием PPU будет достигнут новый уровень взаимодействия графики и физики: все процессы в окружающей героя среде будут подчиняться соответствующим законам физики, и выглядеть это будет максимально реалистично. Так что ждем-с.

Итак, в этом году я задумался над сменой видеокарты ATI Radeon x1650 на новую и хоть сторонник видеокарт AMD-ATI, но хотелось у себя на ПК наблюдать «физику» в любимой игре «Batman: Arkham Asylum».

Была мысль купить слабенькую видеокарту nVidia для «физики» или купить что-то получше nVidia для самостоятельной обработки «физики». Побродив по форумам, решил купить GeForce GTX 560 Ti. Почему, сейчас объясню. Но перед тем, как рассказать об использовании физики в играх, опишу технологию ATI Stream Computing от AMD-ATI.

ATI Stream

Технология ATI Stream Computing - альтернатива nVidia CUDA и физика в играх. Широко применяется, в первую очередь, в сфере обработки мультимедийных данных. С помощью вычислительных ресурсов видеокарт значительно ускорится работа многих популярных приложений для редактирования видео, звука и изображений.

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

Однако не стоит забывать о применении ATI Stream Computing в играх. Ее возможности позволяют разработчикам компьютерных игр поднять спецэффекты и искусственный интеллект персонажей на новый качественный уровень.

Начиная с серии Radeon HD 4000 можно опробовать возможности технологии потоковых вычислений. Значительно ускорилась работа видеоконвертера ATI Avivo Video Converter.

Что касается ПО, адаптированного к технологии AMD, их число постоянно растёт: Microsoft, Adobe, CyberLink и ArcSoft. Поддержка аппаратного ускорения уже есть в Adobe Acrobat Reader, Adobe Photoshop CS4, Adobe Flash 10, Adobe After Effects CS4, Microsoft Office PowerPoint 2007, ArcSoft TotalMedia Theater, CyberLink PowerDirector 7.

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

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

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

Первые ласточки реализации «физики» были в игре «Counter-Strike» (кучность пулемёта ухудшалась при длительной стрельбе) и «Doom 3» (сколько было радости, когда в тумане от фонарика появлялась радуга) или «Unreal Tournament» и во всех играх на ее движке.

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

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

Рис. 1. Человек притягивает мусор

Физика от ATI

Так вот, в 2006-2007 гг. появилась много сообщений о разработке физики в играх, чтобы значительно улучшить реалистичность создаваемого изображения и поведения объектов. Тогда, ещё независимая, ATI разработала и продемонстрировала свою технологию ATI Phisics (рис. 1,2,3) на базе концепции Havok FX, основная суть которой заключалась в использовании мощностей видеокарт для ускорений определённых физических вычислений.

Рис. 2. Падающие шахматные фигуры

Havok FX должен был использоваться только на компьютерах, оснащённых минимум двумя видеокартами в режиме SLI или CrossFire. При этом одна видеокарта из этой связки должна была полностью выделяться для физических вычислений.

Рис. 3. Имитация дыма

Тогда ATI обещал, что достаточно иметь минимум две видеокарты, одна из которых будет в качестве ускорителя «физики»! Разумеется, без ограничений не обошлось, «старый» Radeon должен быть не нижет уровня X1600. Потому что, расчёт физических эффектов выполняется шейдерными блоками GPU, которые были значительно улучшены в семействе ATI Radeon X1x00.

Intel всем доказывала, что лучше всего использовать для этого многоядерные, и только Intel ;), процессоры. Но и Intel и ATI обещали, как только выйдет новый DirectX (тогда ещё ver.10), так сразу и почувствуете физику в играх.

Но обещанную «физику» дал только DirectX 11, включив возможность использовать все ядра процессора аппаратно, а не как в DirectX 10 программно (в DirectX 9 этого вообще не было), загружая их на полную.

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

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

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

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

Рис. 4

А что же nVidia?

Но вернёмся к продвижению физических процессов в играх. nVidia тоже тогда пыталась что-то придумать по этому поводу, но дальше лейбла (SLI Physics) (рис. 4) и идей не пошла.

Рис. 5

Была ещё тогда компания Ageia (рис. 5), которая разработала свой движок PhysX и плату-ускоритель физики (PPU - Physics Processing Unit) на собственном одноименном чипе. Процессор PhysX, состоял из 125 миллионов транзисторов и включал в себя ядро общего назначения, управлявшее массивом SIMD-процессоров.

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

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

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

Технология называлась Hardware Scene Manager (HSM). Физический движок PhysX SDK состоит из трёх главных компонентов по обработке физики: обработка твёрдых тел, обработка тканей, обработка жидкостей.

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

После того, как компания nVidia в 2008 г. приобрела Ageia, PhysX полностью перешёл в собственность nVidia. PhysX SDK распространяется бесплатно и накладывает на разработчиков лишь необходимость указания в программном продукте информации об используемом физическом движке, а так же отображения логотипа компании nVidia на этапе загрузки программного продукта.

Поддержка PhysX SDK была интегрирована в структуру CUDA и стала доступная для всех видеокарт производства nVidia, начиная с серии 8ххх, под Windows XP. Физический движок PhysX SDK теперь известен как nVidia PhysX SDK. Таким образом, необходимость в выделенном физическом процессоре PhysX отпала.

28 июня 2008 года Эран Бадит, участник ресурса NGOHQ.com, запустил аппаратную поддержку PhysX SDK на видеокарте Radeon HD 3870. Создал бета-версию патча для драйверов nVidia. Данный неофициальный патч перехватывает и отменяет блокировку работы PhysX, если в системе обнаружен видеоадаптер от AMD.

Вначале компания nVidia отреагировала на инициативу Эрана Бэдита негативно, заявив, что это невозможно. Однако Бэдиту предложили потом вступить в команду разработчиков nVidia, открыли доступ к документации, SDK, аппаратному обеспечению и дали контакты инженеров.

Было обещано, что модифицированные драйверы для карт ATI скоро станут доступны для загрузки. В свою очередь компания ATI официально не поддержала инициативу Бэдита. Для написания официальных (не модифицированных) драйверов ATI с поддержкой PhysX компания nVidia предлагает лицензировать аппаратную поддержку CUDA, которая включает в себя PhysX. Однако технология CUDA конкурирует с технологией AMD FireStream.

В графических драйверах nVidia версии 186 была заблокирована возможность совместной работы двух графических карт, на которые установлены графические процессоры от разных производителей (AMD и nVidia).

Таким образом, если раньше была возможность разделения вычислений по разным графическим картам, например, карта с процессором nVidia могла рассчитывать игровую физику, а карта с процессором AMD заниматься рендерингом изображения, то с версии 186 эта возможность заблокирована, даже если в системе обнаружен интегрированный GPU другого производителя.

Кроме того, движок PhysX новой версии не поддерживает специализированные физические ускорители (PPU) PhysX, разработанные ещё Ageia, если в системе обнаружен GPU, выпущенный не nVidia. Также пропала и поддержка PhysX и на CPU. Последним «достижением» на этой ниве является отказ nVidia от поддержки старых видеокарт, в новых версиях драйверов для Windows 7.

Как быть?

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

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

Рис. 6

Если хотите увидеть «физику», например, в игре «Batman: Arkham Asylum» (рис. 6), то достаточно иметь видеокарту вроде GeForce GTX 260 или GeForce GTX 280, тогда особого смысла ставить для физики отдельную карту нет т.к. им и так хватает мощности и для графики и для физики.

Достаточно включить PhysX, но игры, которые требуют установленную карту как минимум GeForce GTX 280, могут не позволить включить физику. Однако, это закономерно влечёт за собой проблему.

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

Видеокарты nVidia с менее чем 32 шейдерными ядрами не поддерживают PhysX. Вставить «физическую» видеокарту (идеально подходят GeForce GTX 260 или GeForce GTX 280, хотя сейчас без проблем справляется GeForce GT 240 от 512 Мбайт и выше) можно в PCI-E х16 или х8, или х4 слот, что абсолютно несущественно проявится в падении производительности. При этом версия слота (1.0 или 2.0) не имеет большой разницы (рис. 7-10).

Рис. 7

Рис. 8

Рис. 9

Рис. 10

На графиках видно, что при отключенной физике балы теста одинаковы для всех вариантов подключения GeForce GTX 560 Ti, кроме одиночной GeForce GTX 560 Ti. Это можно объяснить тем, что сильно нагрузить (без включения PhysX) видеокарту игра не способна.

К тому же не всегда дополнительная видеокарта для обработки физики (на диаграммах указаны эти видеокарты после знака «+») приносят пользу. Хотя если в качестве дополнительной видеокарта GeForce GTX 295, то пользы от нее больше, нежели от GeForce GTX 560 Ti. Могу предположить, что проблема в драйверах, а также в скорости PCI-E, в который установлена «физическая» видеокарта.

Однако установка дополнительной карты не всегда возможна или желательна, а двухпроцессорные GeForce редко встречается в продаже и дороги. Кстати, есть уникальные видеокарты, оснащённые отдельным ядром для ускорения PhysX - GeForce GTX 275 CO-OP PhysX Edition от EVGA. Видеокарты GeForce GT 460 и выше не сильно нуждаются в дополнительном ускорителе физики.

«А как же AMD»?

… спросят поклонники AMD - ATI.

Они все время молчали. Им было не до этого (слияние с ATI). В связи с тем, что 15 сентября 2007 года фирма Intel выкупила фирму Havok, то «Havok FX» был отменён.

Но вот в 2009 году официальным пресс-релизом корпорация AMD дала старт программе под названием Open Physics Initiative. Ее задача - «вывести на новый уровень реализм в играх, симуляторах и популярных приложениях».

Практическим шагом, заложившим основу программы, стало подписание соглашения между AMD и Pixelux Entertainment. Корпорация AMD подчёркивает, что делает ставку на открытость технологии. Результатом функционирования должно быть существенное расширение применения технологии физических расчётов в реальном времени при помощи бесплатного «движка» Bullet Physics, распространяемого в исходных текстах.

Чтобы стимулировать разработку программного обеспечения, использующего OpenCL (Open Computing Language) и Bullet Physics, корпорации AMD и Pixelux предлагают универсальный подход, подходящий для игровых консолей, ПК и прочих аппаратных платформ.

В течение многих лет Pixelux совершенствует систему физических расчётов Digital Molecular Matter (DMM) System, в основе которой лежит использование метода конечных элементов. Раньше DMM была закрытой разработкой Pixelux, но теперь ее сможет использовать широкий круг разработчиков, так как оная будет встроена в Bullet Physics.

Подобно тому, как технология ATI Stream сейчас даёт разработчикам ПО возможность использовать в своих программах совместную работу нескольких CPU и GPU, так Bullet Physics сделает широкодоступными разработки Pixelux.

По замыслу партнёров, преимущества DMM будут доступны для систем, поддерживающих OpenCL и DirectX 11 (AMD продаёт соответствующие механизмы в DirectCompute API). Новейшие графические продукты, такие, как серия GPU ATI Radeon HD 5800, обеспечивают невероятное качество визуализации и высокую производительность.

Вкупе с физическим моделированием они способны сделать новый шаг в реалистичном изображении того, как игровые объекты движутся, деформируются и разбиваются на части. Что же, если (или правильнее - когда) совместные усилия AMD и Pixelux Entertainment приведут к успеху, судьба закрытой разработки, коей является NVIDIA PhysX, представляется незавидной.

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

AMD не просто занимается критикой конкурентов, но также и продвигает открытую архитектуру для просчёта физики в играх Open Physics Initiative. AMD даже хотела реализовывать в своих продуктах поддержку движка PhysX и платформы CUDA.

Подведу итог

Сейчас все разработчики физики разделились между тремя доступными вариантами: PhysX, Havok или создание их собственного физического движка.

Уже наверно заметили, что для обработки физики также используются шейдеры в технологиях CUDA от nVidia и ATI Stream.

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

Источник: codingclub

ВОЗМОЖНОСТИ СУЩЕСТВУЮЩИХ ДВИЖКОВ

НЕ ИМЕЕТ СМЫСЛА МНОГО ГОВОРИТЬ О ТОМ, ЧТО В СОВРЕМЕННЫХ ИГРАХ ОЧЕНЬ ЧАСТО ИСПОЛЬЗУЮТСЯ ФИЗИЧЕСКИЕ СИМУЛЯЦИИ РАЗЛИЧНОГО РОДА. ФИЗИКА УЖЕ ДАВНО (И НАДОЛГО) ПРОТОПТАЛА ДОРОЖКУ В СИМУЛЯТОРЫ, В ОСНОВНОМ АВТОМОБИЛЬНЫЕ

Физика используется и как основной элемент геймплея (хардкорные симуляторы), и как средства к получению дополнительных эмоций у игрока (различного рода разрушения). Также есть ряд жанров, в которых массовое применение физики началось сравнительно недавно - это прежде всего шутеры и игры с видом от третьего лица. Спектр использования физических эффектов в них очень широк: от достаточно простых rag-dolls и пинания ящиков до попыток завязать часть геймплея на физику (Half-life 2, Psi-ops и т.д.). Кроме всего перечисленного, существует ряд игровых жанров, в которых физика не нужна в принципе, к примеру в пошаговых глобальных стратегиях. В целом на сегодня физика в играх является важнейшим элементом, но несмотря на это раскручена не так, как графика.

немного терминологии

физический движок (фд)

ФД - библиотека, которая рассчитывает физические взаимодействия между объектами игрового мира (симулируется физика, описываемая законами Ньютона). Физические движки, используемые при разработке игр, как правило, не симулируют физические процессы игрового мира со 100% точностью, а лишь производят достаточно точную аппроксимацию физических законов. Современные игровые физические движки состоят из двух частей: подсистемы определения столкновений и подсистемы расчета физических взаимодействий.

подсистема определения столкновений

Основные два параметра подсистемы определения столкновений: скорость работы и точность определения столкновений. Недостаточная точность приводит к появлению разных артефактов, таких как перекрытие объектов, неопределение столкновений при существенно разных размерах и скоростях объектов и т.д. Для ускорения работы подсистемы столкновений используют различного рода разбиения пространства на подпространства, такие как quadtree (рекурсивное деление пространства на четыре подпространства) или осtree (деление на восемь подпространств), для снижения количества проверок столкновений. Системы столкновений работают дискретно - столкновения рассчитываются через определенные промежутки времени. Итак, такого рода системы могут приводить к тому, что столкновения с участием быстро движущихся объектов не фиксируются - для борьбы с подобного рода артефактами некоторые системы столкновений поддерживают так называемый continuous collision detection (CCD) (системы непрерывного отслеживания столкновений). Суть метода continuous collision detection заключается в том, что проверка столкновений между двумя объектами производится не между ними самими в дискретные моменты времени, а между вытянутыми объемами, которые представляют движение объектов в течение всего временного шага.

подсистема симуляции (пс)

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

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

На базе физики твердого тела реализуется также физическое поведение персонажей и широко известный эффект тряпичной куклы (rag-doll), который заключается в том, что персонаж (чаще всего мертвый) падает вниз, как тряпичная кукла. Для реализации подобного рода поведения только твердых тел недостаточно. Используются так называемые сочленения (joint) или ограничения (constraint).

Джоинт - это точка, которая соединяет два твердых тела (соединение обычно задается относительно точки джоинта) и накладывает ограничения на положение тел в пространстве друг относительно друга или на скорости тел относительно друг друга. Типов джоинтов много (некоторые движки позволяют писать собственные). Для реализации рэгдолов используют ball-joint и hinge-joint. Ball-joint - это шарнирное соединение двух тел, оно ограничивает перемещение тел друг относительно друга и налагает ограничение на то, как повернуты тела относительно друг друга по трем осям (при помощи джоинтов такого типа в регдолле крепится плечо или голова к телу). Hinge-joint - это петельное соединение двух тел, которое ограничивает повороты тел относительно друг друга одной осью. В целом же спектр применения джоинтов очень широк и не ограничивается только созданием rag-dolls.

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

физика и разработка игры

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

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

В зависимости от выбора и требований к физике сложность разработки может значительно колебаться. Если же рассматривать одну и ту же игру с физикой и без нее, при прочих равных, то вариант с физикой (достаточно объемной) затронет всех участников производственного процесса. Наличие физики прежде всего влияет на архитектуру кода игры: введение такой сложной подсистемы влияет и на графику, и на искусственный интеллект, и даже на ввод пользователя.

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

Добавление физики в игру усложняет процесс разработки продукта и требует дополнительных ресурсов.

обзор существующих решений

До недавнего времени ситуация на рынке физических движков была довольно стабильна. Существовало несколько бесплатных физических движков (разного качества), а также ряд коммерческих физических движков. Однако в ушедшем 2005 году компания AGEIA анонсировала первый в истории игровой индустрии ускоритель физики, который снимает с центрального процессора задачу расчета физики. Ускоритель пока еще не появился в продаже, но его создатели утверждают, что их продукт будет способен обсчитывать порядка 40 000 объектов (на данный момент количество физических объектов, обсчитываемых на ПК, составляет десятки).

Ниже рассмотрим основные физические движки, которые существуют на сегодня. Помимо чисто физических движков, существует масса игровых движков, которые содержат физические подсистемы, написанные поверх одной из библиотек (на www.devmaster.net/engines можно ознакомиться с игровыми движками).

PhysX (www. ageia.com, коммерческий)

Эта физическая технология предоставляется компанией AGEIA и как физический движок, и как АПИ для работы с их физическим ускорителем. На данный момент ряд игровых компаний заявили о поддержке этой технологии в своих продуктах (в том числе Unreal Engine).

Возможности PhysX:

СИМУЛЯЦИЯ ТВЕРДЫХ ТЕЛ, В КАЧЕСТВЕ ФИЗИЧЕСКОГО ПРЕДСТАВЛЕНИЯ МОГУТ ИСПОЛЬЗОВАТЬСЯ ПРИМИТИВЫ (ПЛОСКОСТИ, БОКСЫ, КАПСУЛЫ) И ВЫПУКЛЫЕ МНОГОУГОЛЬНИКИ, А ТАКЖЕ ИХ КОМБИНАЦИИ;

ПОЛНОСТЬЮ НАСТРАИВАЕМЫЕ ДЖОИНТЫ С ШЕСТЬЮ СТЕПЕНЯМИ СВОБОДЫ;

СИМУЛЯЦИЯ ЖИДКОСТЕЙ;

ФИЗИЧЕСКОЕ ВЗАИМОДЕЙСТВИЕ МЕЖДУ ЖИДКОСТЯМИ И ТВЕРДЫМИ ТЕЛАМИ;

КОНТРОЛЛЕРЫ ПЕРСОНАЖЕЙ (ПЕРСОНАЖ МОЖЕТ СОСТОЯТЬ ИЗ БОКСОВ И КАПСУЛ), ПОЗВОЛЯЮЩИЕ АВТОМАТИЧЕСКИ ПЕРЕМЕЩАТЬСЯ ПО ЛЕСТНИЦАМ;

АВТОМОБИЛИ НА ОСНОВЕ ТРЕЙСИНГА ЛУЧА;

ПОДДЕРЖКА НЕСКОЛЬКИХ СЦЕН;

СИСТЕМА СТОЛКНОВЕНИЯ ПОДДЕРЖИВАЕТ НЕПРЕРЫВНОЕ ОТСЛЕЖИВАНИЕ СТОЛКНОВЕНИЙ;

МУЛЬТИПЛАТФОРМЕННОСТЬ;

МНОГОПОТОЧНОСТЬ.

Havok (www.havok.com, коммерческий)

Один из старейших физических движков. На нем сделаны десятки игр (посмотреть их список можно по адресу www.havok.com/content/blogcategory/29/73). Недавно Havok анонсировал новую технологию расчета физики Havok FX, которая производит расчеты физики на видеокартах используя шейдеры 3.0.

Возможности Havok:

ФИЗИКА ТВЕРДОГО ТЕЛА;

ДЖОИНТЫ;

КОНТРОЛЛЕРЫ ПЕРСОНАЖЕЙ (ПОЗВОЛЯЮТ ПЕРСОНАЖАМ ПЕРЕМЕЩАТЬСЯ ПО ЛЕСТНИЦАМ);

МУЛЬТИПЛАТФОРМЕННОСТЬ;

МНОГОПОТОЧНОСТЬ.

Trueaxis (www.trueaxis.com)

Бесплатный для некоммерческого использования. Исходники закрыты.

Возможности:

ФИЗИКА ТВЕРДОГО ТЕЛА;

СИСТЕМА СТОЛКНОВЕНИЯ ПОДДЕРЖИВАЕТ НЕПРЕРЫВНОЕ ОТСЛЕЖИВАНИЕ СТОЛКНОВЕНИЙ;

В КАЧЕСТВЕ ПРЕДСТАВЛЕНИЯ МОГУТ ИСПОЛЬЗОВАТЬСЯ ВЫПУКЛЫЕ МНОГОУГОЛЬНИКИ, КАПСУЛЫ, ЦИЛИНДРЫ И СФЕРЫ;

ПОДДЕРЖКА СИМУЛЯЦИИ АВТОМОБИЛЕЙ;

ДЖОИНТЫ.

ODE (www.ode.org, BSD, исходники открыты)

Единственный в списке движок с открытыми исходниками, что позволяет ему служить в качестве базы для построения собственного физического движка (небезызвестный проект S.T.A.L.K.E.R. использует модифицированный ODE), а также просто для изучения того, как оно все внутри устроено. ODE очень часто используется различными игровыми движками в качестве физической подсистемы.

Возможности:

ФИЗИКА ТВЕРДОГО ТЕЛА;

ДЖОИНТЫ;

СИСТЕМА СТОЛКНОВЕНИЙ ОТДЕЛЕНА ОТ ФИЗИЧЕСКОЙ СИМУЛЯЦИИ, ЧТО ПОЗВОЛЯЕТ ИНТЕГРИРОВАТЬ ODE С РАЗНЫМИ СИСТЕМАМИ СТОЛКНОВЕНИЙ.

Tokamak (www.tokamakphysics.com, беcплатный, исходники закрыты)

Возможности:

ФИЗИКА ТВЕРДОГО ТЕЛА;

ДЖОИНТЫ (ВСЕГО ДВА ВИДА: BALL И HINGE - ДОСТАТОЧНО ДЛЯ ПОСТРОЕНИЯ RAG-DOLLS).

Newton (www.physicsengine.com, беcплатный, исходники закрыты)

Возможности:

СИСТЕМА СТОЛКНОВЕНИЯ ПОДДЕРЖИВАЕТ НЕПРЕРЫВНОЕ ОТСЛЕЖИВАНИЕ СТОЛКНОВЕНИЙ;

ФИЗИКА ТВЕРДОГО ТЕЛА;

ПОДДЕРЖКА СИМУЛЯЦИИ АВТОМОБИЛЕЙ.

физика на примере

Для практического примера возьмем демонстрационную программу из OPAL (open physics abstraction layer: http://ox.slug.louisville.edu/opal/wiki) - это открытый физический движок, предоставляющий единый высокоуровневый интерфейс для работы с другими физическими движками. На данный момент существует единственная реализация поверх ODE, в разработке находится оболочка над TrueAxis. Для работы необходимо скачать сам движок - ?download.

Нас интересует дема, которая находится в папке opal-0.3.1-srcsamplessimple и показывает базовые аспекты работы с физическим движком OPAL, демонстрируя работу с твердыми телами. В качестве визуализатора используется библиотека SDL (www.libsdl.org/index.php). Приложение состоит из единственного файла main.cpp и нескольких h-ков. При старте появляется статический бокс. При нажатии клавиши «пробел» на этот бокс падают твердые тела, представляемые при помощи различных примитивов. Рассмотрю файл main.cpp и прокомментирую те его части, которые относятся к физической симуляции.

набор глобальных переменных

std::vector gEntities;

opal::Simulator* gSimulator = NULL;

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

Переменная gEntities содержит список сущностей типа opalSamples::Entity, которые имеют физическое представление. Сам класс и его наследники мало интересны, так как они в данной программе служат для отрисовки симулируемых объектов. В самом классе opalSamples::Entity интересует нас одно поле - opal::Solid* mSolid. Тип opal::Solid представляет твердое тело в физическом движке OPAL. Твердое тело обладает позицией, скоростью, ускорением и является базовой единицей симуляции - такого рода сущность есть в любом физическом движке. В данной программе для рисования сущности необходимо знать позицию твердого тела - эта информация получается путем вызова метода getTransform у mSolid.

содержимое функции main

gSimulator = opal::createSimulator();

gSimulator->setGravity(opal::Vec3r(0, (opal::real)-9.81, 0));

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

1. opal::Solid* platformSolid = gSimulator->createSolid();

2. platformSolid->setStatic(true);

3. opal::BoxShapeData boxShape;

4. boxShape.dimensions = gGroundDimensions;

5. platformSolid->addShape(boxShape);

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

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

В третьей строчке создаем экземпляр структуры boxShape, которая описывает трехмерный прямоугольник (бокс).

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

Matrix44r offset;

Material material;

Поле offset задает смещение фигуры относительно центра твердого тела, поле material задает свойства материала фигуры. В OPAL"е материал имеет следующие свойства:

hardness - от 0 до 1. Показывает, насколько допустимо перекрытие объемов тел.

friction - от 0 до 1, трение движения. Чем больше это значение, тем быстрее будет останавливаться движущееся тело.

bounciness - от 0 до 1, упругость. Чем больше значение, тем больше энергии будет поглощаться при соударении.

density - плотность материала. На основании этого параметра и объема фигуры вычисляется масса фигуры.

основной цикл программы (вернее, те его части, которые представляют интерес в контексте рассматриваемого вопроса)

opal::real dt = (opal::real)timer.getElapsedSeconds();

gQuit = processInput();

gSimulator->simulate(dt);

Нам интереснее всего вот эта строчка:

gSimulator->simulate(dt);

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

gSimulator->destroy();

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

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

• Tutorial

Мой странный творческий путь занес меня в разработку игр. Благодаря отличной студенческой программе от IT-компании, название которой СостоИт из одной Греческой МАленькой буквы, сотрудничающей с нашим университетом, удалось собрать команду, родить документацию и наладить Agile разработку игры под присмотром высококлассного QA-инженера (здравствуйте, Анна!)

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

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

Игра

Гифка с игрой

Пару слов о том, как она сделана.
Сделана с помощью Blender и пары скриптов на питоне. На время съемки, в углу экрана находились 16 квадратиков, цвет которых кодировал 32 бита числа с плавающей запятой - вращение телефона в данный момент времени. R, G - данные, B - четность. 0 - 0, 255 - 1. Снятое на компьютере видео разбивалось на кадры с помощью ffmpeg, каждому кадру рендера в соответствие ставился расшифрованный угол. Такой формат позволил пережить любое сжатие в процессе съемки и поборол тот факт, что все программы имеют несколько разные представления о течении времени. В реальности игра играется так же как и на рендере.

Проблема 1: Бесконечность

1. Игнорирование. В Minecraft, например, ошибки округления лишь сделали игру интереснее, породив феномен «Далеких Земель» .
2. Телепортация в (0;0;0) при слишком сильном удалении самолетика от начала координат.
3. Смена точки отсчета. Движется не самолет, а уровень вокруг него.

Проблема 2: Генерация уровня

Есть несколько основных подходов к строительству endless runner"ов:

1. Использование готовых сегментов уровня, которые стыкуются случайным образом. Так сделано, например, в Subway Surfers. Это просто реализовать, но игрок к этому быстро привыкает и знает, к чему готовиться, что скучно.
2. Уровень - просто прямая, на которой случайным образом расставляются препятствия. Так сделано в Joypack Joyride и Temple Run. В нашем случае, это сильно ограничило бы количество маневров.
3. Все генерируется случайным образом. Самый сложный, непредсказуемый и интересный для игрока вариант.

Структура уровня

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

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

Основные Законы Физики в Unity

1. Коллайдеры не должны двигаться, вращаться, включаться\выключаться и менять размер.

2. Если объект движется или вращается - он должен быть твердым телом т.е. иметь компонент Rigidbody.

3. Если объект является твердым телом - двигаться и вращаться он должен через методы твердого тела.

Есть три уровня управления твердым телом:

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

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

Есть еще одна особенность Unity, не относящаяся к физике, но достойная упоминания: динамическое создание и удаление объектов через методы Instantiate/Destroy - БЕЗУМНО медленный процесс. Я боюсь себе даже представить, что там происходит под капотом во время создания объекта. Если вам нужно создавать и удалять что-то динамически - используйте фабрики и заправляйте их нужными объектами во время загрузки игры. Instantiate должен вызываться в крайнем случае - если у фабрики вдруг закончились свободные объекты, а про Destroy забудьте навсегда - все созданное должно использоваться повторно.

Применение законов на практике

Уровень, очевидно, должен вращаться и двигаться.
Облегчим себе жизнь навечно, разместив ось вращения уровня - самолетик - в начале координат. Теперь мы сможем вычислять расстояние от точки до него, вычисляя длину вектора координат точки. Мелочь, а приятно.
Совместное движение объектов легко реализуется через иерархию объектов в Unity, потому что дети являются частью родителя. Например, описанная структура уровня логично реализуется следующим образом:
- Ось вращения
- - \ Уровень
- - - \ Сегмент 1
- - - - \ Блок 1 (Collider)
- - - - \ ...
- - - - \ Блок N
- - - \ Сегмент 2 ...
- - - \ Сегмент 3 ...
- - - \ Сегмент 4 ...
(Можно даже обойтись без объекта уровня)

Скрипт на оси получает данные с гироскопа и выставляет ей соответствующий угол… И нарушает сразу множество правил, потому что вращение передастся по иерархии на коллайдеры, что сведет физический движок с ума. Придется делать ось твердым телом и вращать ее через соответствующий метод. Но что с движением уровня? Очевидно, что ось вращения и объект уровня перемещаться не будут, каждый сегмент нужно двигать персонально, иначе мы сталкиваемся с проблемой бесконечности. Значит, твердыми телами должны быть сегменты. Но у нас уже есть твердое тело выше в иерархии и твердое тело не может быть частью твердого тела. Логичная и элегантная иерархия не подходит, все придется делать руками - и вращение, и перемещение, без использования объекта для оси вращения. Будьте готовы к такому, если у вас уникальные геймплейные фичи.

Если двигать непосредственно сегменты пришлось бы и так, то вращать их придется вынужденно. Основная сложность в том, что в физическом движке Unity нет метода «вращать объект вокруг произвольной точки» (он есть у Transform, но не искушайтесь). Есть только «вращать вокруг своего центра». Это логично, потому что вращение вокруг произвольной оси - одновременно и вращение, и движение, а это две разные операции. Но его можно имитировать. Сначала вращаем сегмент вокруг своей оси, потом вращаем координаты «своей оси» вокруг самолета. Благодаря тому, что самолет у нас в начале координат, не придется вспоминать даже школьную геометрию и лезть в википедию, в Unity уже все есть. Достаточно перевести угол поворота в кватернион и умножить его на координаты точки. Кстати, узнал я об этом прямо во время написания статьи, до этого использовалась матрица поворота.

У нас есть враги, которые отталкивают самолет в стену, надеясь убить. Есть щит, который отталкивает самолет от стен, помогая выжить. Реализовано это тривиально - есть вектор смещения, который каждый кадр прибавляется к координатам каждого сегмента и сбрасывается после этого. Любой желающий пнуть самолетик, через специальный метод, может оставить вектор своего пинка, который прибавится к этому вектору смещения.

В конечном итоге, настоящие координаты сегмента, каждый кадр, вычисляются центром управления движением уровня как-то так:
Vector3 position = segment.CachedRigidbody.position; Vector3 deltaPos = Time.deltaTime * Vector3.left * settings.Speed; segment.truePosition = Quaternion.Euler(0, 0, deltaAngle) * (position + deltaPos + movementOffset);
После всех вычислений и костылей, необходимых для работы точной стыковки сегментов при регенерации, segment.truePosition отправляется в метод MovePosition твердого тела сегмента.

Выводы

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

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