Физика в компьютерных играх. Применение законов на практике. Упрощённая физика машин и персонажей в Grand Theft Auto V

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

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

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

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

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

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

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

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

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

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

Пусть есть две частицы, координаты первой 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).

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

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

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

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