Законы физики в компьютерных играх. Примеры превосходной игровой физики. Написание своего движка

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

Физика может определять центральные игровые механики, как в Portal и Where’s My Water?, или поддерживать их – например, постройка башен в World of Goo и потрясающее разрушение мира в Red Faction Guerilla. Она может даже передавать эмоции – когда в Limbo вы тянете паука за ногу, можно почувствовать, как он напрягается от боли. Может служить для усиления эстетического удовольствия, как .

Физика помогает вызывать восторг и удивление. Помогает добиваться реализма или же сюрреализма. Вообще, при правильном её применении, игры становятся интереснее. И она запросто может привлекать аудиторию не только к головоломкам, но и к симуляторам, платформерам и даже шутерам.

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

Гравитация в Mario Galaxy

Разработчик Gravity Ghost Эрин Робинсон (Erin Robinson) называет Super Mario Galaxy основным источником вдохновения для своей механики передвижения. Возможно, прыжки по планетоидам в этой игре и нарушают законы физики, но использование гравитации позволило воплотить в жизнь великолепный дизайн уровней.

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

Что интересно, эта гравитация действует не на все объекты в игре.

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

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

Портальные пушки в Portal, нарушающие законы физики

Замечательная гравипушка из Half-Life 2, позволяющая хватать, перемещать и швырять объекты окружения, получила достойного идейного наследника в играх Portal. Портальная пушка создаёт червоточину размером с человека, позволяющую переноситься из одной видимой точки в другую. Эта возможность искривлять реальность (игровую) позволила команде разработчиков придумать по-настоящему оригинальные головоломки.

Разработчик Manifold Garden Уильям Чир (William Chyr) говорит, что Portal служит моделью для обучения непривычной физике. «Игра разбивает концепцию на несколько базовых шагов, которые понятны всем», – говорит он, – «и при этом не затягивает с обучением». Механика порталов так бережно согласована, что ошибки относительно безболезненны, а решения всегда логичны (особенно радуют продвинутые манёвры – например, когда помещаешь порталы один над другим, чтобы Челл набрала скорость для прыжка через широкую пропасть).

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

Симуляция физики как игра в Turbo Dismount (и не только)

Реалистичная физика может быть увлекательна сама по себе. Игры без чёткой цели, вроде Garry’s Mod, BeamNG.drive и Turbo Dismount (среди прочих) полностью полагаются на забавы с системой игровой физики.

В Garry’s Mod заложена мощная строительная составляющая, позволяющая манипулировать с любыми моделями и объектами; BeamNG.drive – просто игровая площадка с автомобилями, повреждения которых основаны на гиперреалистичной физической модели. Ну а в Turbo Dismount вы наслаждаетесь не столько строительством и передвижением, сколько поиском всё более изощрённых способов поиздеваться над ragdoll-персонажем. Если заглянуть в мир цифровых игрушек поглубже, можно найти Earth Primer, которая учит геонаукам посредством весёлых взаимодействий в небольшой песочнице.

Генеральный директор Bossa Studios Энрике Олифьерс (Henrique Olifiers) отмечает, что подобные игры наглядно демонстрируют развлекательную самодостаточность симуляции физики. «Физика сама по себе может быть интерактивным развлечением», – полагает он. Turbo Dismount и другие подобные игры – по сути просто набор базовых взаимодействий, реакция на которые определяется системой физики, и уже это способно увлекать на долгие часы.

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

Упрощённая физика машин и персонажей в Grand Theft Auto V

Являет нам особую вариацию физики, которая делает игровой мир реалистичнее, но в то же время позволяет вытворять нелепые и нереальные безумства. «Всё вокруг изо всех сил старается изображать реальность, до тех пор пока эта «реальность» не встаёт на пути весёлого геймплея», – объясняет Олифьерс. Физика движения персонажей и автомобилей – равно как баллистика и взрывы –«нормальна» именно по меркам Лос-Сантоса.

Наверное, так и задумано, что различные крайности обладают особенно высоким потенциалом для забав с физикой. Олифьерс замечает, что GTA V – опора сабреддита /r/GamePhysics, благодаря мириадам интересных особенностей, багов, эксплойтов и невероятных трюков, связанных с физикой.

Разработав систему физики, которая с радостью портит всё погружение при первой же возможности устроить полнейший хаос, Rockstar гарантировала, что в открытом песочном мире Grand Theft Auto V всегда найдётся место гонкам и разрушениям.

Полёты на вингсьюте в Just Cause 3

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

Дизайнер QWOP и профессор кафедры Game Center в Нью-Йоркском Университете Беннетт Фодди (Bennett Foddy) называет вингсьют «образцом идеально отлаженной игровой механики, гармонирующей с системой физики». Он вызывает чувство постоянного баланса на грани катастрофы, неважно, парите вы аккуратно, устремляетесь вниз орлом или резко взлетаете на склон. Но учиться им управлять, понимая особенности набора высоты, торможения и инерции – в особенности, осваивая костюм в сочетании с крюком – значит учиться летать. Немногие игры подарят вам это ощущение.

Если главным приоритетом выступает удовольствие от игры, разрабатывайте механики, избавляющиеся от полной достоверности. Но сохраняйте их правдоподобными и гармонирующими с игровым миром. Just Cause 3 тому пример – одна основанная на физике механика способна полностью вас очаровать.

Эластичный и пружинистый мотоцикл в Elasto Mania

Некогда бывшая сферой интереса студентов по всему миру, Elasto Mania остаётся выдающимся образцом геймплея, основанного на физике. Похожая на более свежую серию Trials, но более абстрактная и ориентированная на головоломки, Elasto Mania даёт вам мотоцикл и отправляет в причудливый мир, напоминающий лабиринт с зазубренными платформами и разбросанными повсюду яблоками. Игра ставит простую задачу: коснуться цветка (и ничего простого в этом нет). Чтобы добраться до цветка, нужно двигаться вдумчиво и аккуратно, поскольку ваш байк не только растягивается, как резинка, и чувствителен к малейшему ускорению, но и сам гонщик толщиной с бумагу умирает от малейшего контакта головы с землёй.

Фодди говорит, что прелесть Elasto Mania заключается в том, как она «демонстрирует, какой может предстать новая комплексная механика, когда физический движок взаимодействует с продуманным дизайном мира». Пять доступных действий (наклон вперёд-назад, ускорение, торможение и смена направления) – это всё, что нужно для управления эластичным заднеприводным мотоциклом на пути через множество препятствий, когда разнообразные решения поставленной задачи подразумевают грамотное использование крутящего момента, гравитации и физики упругих тел (байк, по большому счёту – пружина на колёсах).

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

Конструирование ракет в Kerbal Space Program

Обычно основанная на физике игровая механика подразумевает, что вы будете работать рука об руку с физической системой. Вы либо играете с самой физикой, либо используете её для получения каких-либо преимуществ. Но Kerbal Space Program – одна из тех редких игр, где вам нужно активно бороться с физикой, чтобы сделать хоть что-нибудь. Здесь ключевые механики не просто основаны на физике или подкрепляются ей; здесь они ей противостоят.

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

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

Заключение

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

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

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

  • Tutorial

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

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

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

Игра

Гифка с игрой


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


Самолетик летит по бесконечной и непредсказуемой пещере, в которой есть бонусы, всякие монетки и враги, в которых можно стрелять самонаводящимися ракетами. Врезался в стену - сразу проиграл.
Отличительная особенность игры в том, что уровень прибит к горизонту и управление в ней гироскопическое, причем, абсолютное. Наклонил телефон на 45 градусов - самолетик полетел под углом 45 градусов. Нужно сделать мертвую петлю - придется крутить планшет. Никакой чувствительности нет, только хардкор.
Выделим две основные и очевидные проблемы для разработчика:
Проблема 1: Бесконечность
Unity хранит и обрабатывает координаты объектов в виде обычных 32-битных float, имеющих точность где-то до 6 знака после запятой. Проблема в том, что игра у нас бесконечная и, если мы достаточно долго будем лететь, начнутся различного рода безумные баги, вплоть до телепортации сквозь стены. Есть несколько подходов к решению этой проблемы:
  1. Игнорирование. В Minecraft, например, ошибки округления лишь сделали игру интереснее, породив феномен «Далеких Земель» .
  2. Телепортация в (0;0;0) при слишком сильном удалении самолетика от начала координат.
  3. Смена точки отсчета. Движется не самолет, а уровень вокруг него.
В нашем случае, единственный допустимый вариант - третий, который и был реализован. О реализации - чуть позже.
Первый - игнорирование - абсолютно недопустим. Создание робота, который сможет вечно играть в нашу игру - интересная (и весьма простая) задача, которую кто-нибудь решит. Да и обычных корейских игроков недооценивать не стоит - самолетик быстрый, уровень генерируется непредсказуемо. И если до прохождений сквозь стены лететь и лететь, то куда более точная стрельба начнет очевидно подглючивать уже через 5 минут полета.
Второй - телепортация игрока и всего мира - ставит мобильные устройства на колени, в некоторых случаях - где-то на полсекунды. Это очень заметно, а потому - недопустимо. Но это вполне приемлемый вариант для простеньких бесконечных игр для ПК.
Проблема 2: Генерация уровня

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

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

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

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

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

За месяц разработки, экспериментов и чтения документации, я выделил три основных закона физики в Unity. Их можно нарушать, но плата за нарушение - производительность. Движок никак не будет предупреждать вас о допущенной ошибке, а без профайлера вы можете никогда о них и не узнать. Несоблюдение этих законов может замедлить вашу игру в десятки раз. Как я понял, нарушение любого закона приводит к тому, что физический движок помечает коллайдер-нарушитель как некорректный и пересоздает его на объекте, с последующим пересчетом физики:
1. Коллайдеры не должны двигаться, вращаться, включаться\выключаться и менять размер.
Как только вы добавили коллайдер на объект - забудьте про какое-либо воздействие на него или объекты, в которых он содержится. Обычный коллайдер - исключительно статический объект. Дерево, например, может быть с одним коллайдером. Если дерево может упасть на игрока - дерево будет падать вместе с производительностью. Если это дерево растет из волшебного питательного облака, которое коллайдера не имеет, но может перемещаться - это будет сопровождаться падением производительности.
2. Если объект движется или вращается - он должен быть твердым телом т.е. иметь компонент Rigidbody.
Про это написано в документации, да. Которую не обязательно вдумчиво читать, чтобы начать делать игру, потому Unity очень прост и интуитивно понятен.
Rigidbody меняют отношение физического движка к объекту. На него начинают воздействовать внешние силы, он может иметь линейную и угловую скорости, а самое главное - твердое тело может двигаться и вращаться средствами физического движка, не вызывая полный пересчет физики.
Существует два типа твердых тел - обычные и кинематические. Обычные тела взаимодействуют друг с другом и обычными коллайдерами - одно тело не может пройти сквозь другое. Кинематические тела следуют упрощенным правилам симуляции - на них не воздействуют никакие внешние силы, гравитация - в том числе. Они свободно могут проходить друг через друга и коллайдеры, а вот обычные твердые тела они отталкивают, как будто имея бесконечную массу.
Если объекты не жалко отдать под контроль физического движка - используйте обычные твердые тела. Например, если вам нужно красиво скатить камни со скалы. Если ваши скрипты или аниматоры управляют объектом напрямую - используйте кинематические тела, так вам не придется постоянно бороться с движком и случайными столкновениями объектов. Например, если у вас анимированный персонаж или управляемая ракета, взрывающаяся при контакте с чем-то.
3. Если объект является твердым телом - двигаться и вращаться он должен через методы твердого тела.
Забудьте про прямое обращение к Transform"у объекта сразу же после добавления к нему коллайдера. Отныне и навсегда, Transform - ваш враг и убийца производительности. Перед тем как написать transform.position =… или transform.eulerAngles = ..., произнесите фразу «я сейчас абсолютно четко понимаю, что делаю, меня устраивают те тормоза, которые будут вызваны этой строкой». Не забывайте про иерархические связи: если вы, вдруг, сдвинете объект, содержащий твердые тела - произойдет пересчет физики.
Есть три уровня управления твердым телом:
- Самый высокий и, следовательно, естественный, уровень - через силы. Это методы AddForce и AddTorque. Физический движок учтет массу тела и правильно посчитает результирующую скорость. Все взаимодействия тел происходят на этом уровне.
- Средний уровень - изменение скоростей. Это свойства velocity и angularVelocity. На их основе вычисляются силы, влияющие на тела при их взаимодействии, а также, очевидно, их положения в следующий момент времени. Если у твердого тела очень маленькая скорость - оно «засыпает», для экономии ресурсов.
- Самый низкий уровень - непосредственно координаты объекта и его ориентация в пространстве. Это методы MovePosition и MoveRotation. На следующей итерации вычисления физики (это важно, поскольку каждый последующий вызов метода в рамках одного кадра заменяет вызов предыдущего) они выполняют телепортацию объекта в новое положение, после которой он живет как раньше. В нашей игре используется именно этот уровень, и только он, потому что он предоставляет полный контроль над объектом.

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

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

Есть еще одна особенность 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 твердого тела сегмента.

Выводы

Насколько все это быстро работает? На старых флагманах - Nexus 5 и LG G2 - игра летает на 60 FPS, с еле заметной просадкой во время включения новых коллайдеров во время генерации сегмента (это неизбежно и никак не обходится) и выдвигания червяков из земли (можно нагородить какой-то ад, чтобы это обойти, но сейчас там осознанное нарушение третьего закона). 40 стабильных FPS выдает любое устройство с гироскопом, которое нам попадалось. Без знания и учета всех законов, производительность была, мягко сказать, неудовлетворительной и телефоны перегревались. Настолько, что я думал написать свой простенький специализированный движок для 2д-физики. К счастью, физика в Unity оказалось достаточно гибкой, чтобы все проблемы можно было обойти и создать уникальную игру, достаточно было лишь пары недель экспериментов.

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

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

Архив - Физика в играх - Журнал «Компьютер»

Итак, в этом году я задумался над сменой видеокарты 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. Среди функций движка заявлены способность обработки движения и взаимодействия частиц в сыпучих материалах, несжимаемых жидкостях, упругих конструкциях, деформации пластиковых материалов и многие другие эффекты.


Учителям остаётся только выбирать, если они, конечно, готовы к этому выбору. Сегодня мы предлагаем вашему вниманию 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 .


Вступление:

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

Моделирование для игры:

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

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

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

Связанные частицы:

Пусть есть две частицы, координаты первой x1, координаты второй x2, где x1 и x2 - вектора. Расстояние между частицами четко задано и равно L. Получается, что между ними существует упругая связь. Для того чтобы восстановить между двумя частицами заданное расстояние, мы должны проделать следующие операции:

vector3f delta = x2-x1; float deltalength = Magnitude(delta) ; float diff = (deltalength-L) /deltalength; x1 = x1+delta*(0 .5 f*diff) ; x2 = x2-delta*(0 .5 f*diff) ;

Где Magnitude() возвращает длину вектора.

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

Сейчас разберемся, с тем, как такую систему частиц перемещать. Казалось бы, чем плохо считать, для каждой частицы, на каждом шаге, её перемещение по формуле x1+=v1*timestep+a1*timestep*timestep/2 ,где v1 - скорость данной частицы, a1 - ускорение данной частицы, а timestep шаг по времени. И скорость еще надо изменить: v1+=a1*timestep. Но дело в том, что после перемещения всей системы нам нужно восстановить начальное расстояние между соединенными частицами. И это может привести к тому, что какая-то частица в итоге сдвинулась вовсе не на рассчитанное нами расстояние, она даже могла уйти в сторону противоположную своей скорости. Что в дальнейшем будет происходить с такой противоречивой системой, я не знаю и знать не хочу.

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

X1+=x1-oldx1+a1*timestep*timestep.

Так в движении системы будет учитываться взаимодействие частиц. Но отсутствие значения скорости сильно усложняет работу с системой частиц.

Поэтому, я решил поступать следующим образом. Сохраним положение частиц. Изменим скорость и расстояние, как в первом методе. После, рассчитав положение частиц в зависимости от связей, скорость каждой частицы вычисляем вот так v=(x-oldx)/timestep. Таким образом, мы учтем взаимодействие частиц между собой.

А так выглядит класс на c++.

struct Constraint { int particleA, particleB; float restlength; }; class ParticleSystemPhys { public : Vector3f m_x[ NUM_PARTICLES] ; // Current positions Vector3f m_oldx[ NUM_PARTICLES] ; // Previous positions Vector3f m_v[ NUM_PARTICLES] ; //velocity Vector3f m_a[ NUM_PARTICLES] ; // acceleration Constraint m_constraints[ NUM_CONSTRAINTS] ; float m_fTimeStep; int NUM_PARTICLES; int NUM_CONSTRAINTS; int NUM_ITERATIONS; void TimeStep() ; private : void Motion() ; void SatisfyConstraints() ; void AccumulateForces() ; };

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

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

Поведение твердых тел при столкновении:

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

Вспомним столкновение упругих шаров. m1,m2 - масса первого и второго шаров соответственно, v1,v2 - проекции скоростей шаров на нормаль столкновения до столкновения, u1,u2 - проекции скоростей шаров на нормаль после столкновения. Запишем законы сохранения импульса и энергии.

M1*v1+m2*v2=m1*u1+m2*u2
m1*v1*v1 /2+m2*v2*v2 /2=m1*u1*u1 /2+m2*u2*u2 /2

Запишем эти уравнения так:

M1(u1-v1)=m2(v2-u2) (*)
m1(u1*u1-v1*v1)=m2(v2*v2-u2*u2)

Разделив второе уравнение на первое, получим:

V1+u1=v2+u2

Умножив обе части уравнения на m2 и сложив с (*) получим

U1=((m1-m2)v1+2*m2*v2)/(m1+m2).

Аналогично

U2=((m2-m1)v2+2*m1*v1)/(m1+m2).

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

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

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

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

Статьи по теме: