FEED Validator

for Atom and RSS and KML

It looks like this is a web page, not a feed. I looked for a feed associated with this page, but couldn't find one. Please enter the address of your feed to validate.

Source: https://gamedev.ru/code/articles/?id=4706

<!DOCTYPE html>
<html lang="ru" itemscope itemtype="http://schema.org/WebPage">
<head>
<meta http-equiv="X-UA-Compatible" content="IE=Edge">
<meta charset="Windows-1251">
<meta name="viewport" content="width=device-width, height=device-height">
<title>Физика «на пальцах»: солверы физических движков / Физика / Статьи / Программирование игр / GameDev.ru — Разработка игр</title>
<meta name="Description" content="Данная статья объясняет принципы работы солверов современных физических движков. В этом очерке я постараюсь объяснить, как работают солверы современных на момент написания статьи...">
<meta name="Keywords" content="Физика, «на, пальцах», солверы, физических, движков, Физика, Статьи, Программирование, игр, GameDev, ru, Разработка, игр">
<link href="https://gamedev.ru/favicon.ico" rel="SHORTCUT ICON">
<link href="https://gamedev.ru/_css/main_1718324380.css" rel="stylesheet" type="text/css">
<script src="https://gamedev.ru/_js/skif_1718666590.js"></script>
<meta name="yandex-verification" content="7262e69d68dab0c9">
<link rel="icon" type="image/png" href="https://gamedev.ru/apple-touch-icon-196x196.png" sizes="196x196">
</head>
<body class="no-mathjax">
<div id="tool">
<div class="bound unselectable">
<div class="scroll-icons">
<button type="button" data-script="Skif_Menu" class="tool"><div class="menutog"></div></button>
<div id="menu" data-visible="0"><div class="content">
<ul>
<li><a href="https://gamedev.ru/news/" title="Новости в области разработки игр">Новости</a></li>
<li class="sel"><a href="https://gamedev.ru/articles/" title="Статьи для разработчиков игр">Статьи</a>
<ul>
<li class="sel"><a href="https://gamedev.ru/code/articles/" title="Статьи по программированию игр">> Код</a></li>
<li><a href="https://gamedev.ru/art/articles/" title="Графический дизайн">Арт</a></li>
<li><a href="https://gamedev.ru/gamedesign/articles/" title="Игровой дизайн">Дизайн</a></li>
<li><a href="https://gamedev.ru/industry/articles/" title="Игровая индустрия, события, интервью">Индустрия</a></li>
</ul>
</li>
<li><a href="https://gamedev.ru/tip/" title="Подсказки">Подсказки</a></li>
<li><a href="https://gamedev.ru/terms/" title="Описание терминов в разработке игр">Термины</a></li>
<li><a href="https://gamedev.ru/faq/" title="FAQ: Ответы на частозадаваемые вопросы">FAQ</a></li>
<li><a href="https://gamedev.ru/pages/" title="Персональные страницы пользователей">Страницы</a></li>
<li><a href="https://gamedev.ru/community/" title="Сообщества: Пользовательские разделы с группами участников">Сообщества</a></li>
<li><a href="https://gamedev.ru/forum/" title="Форум разработчиков игр">Форум</a></li>
<li><a href="https://gamedev.ru/files/" title="Качалка: Файлы и изображения">Качалка</a></li>
<li><a href="https://gamedev.ru/members/" title="Участники проекта GameDev.ru">Участники</a></li>
<li><a href="https://gamedev.ru/users/" title="Регистрации пользователей">Пользователи</a></li>
</ul>
<button type="button" class="flat grey" data-script="Skif_TogleStyle">Тёмная тема</button>
</div></div>
<a href="https://gamedev.ru/" class="tool"></a>
<a href="https://gamedev.ru/pubs" class="tool">Публикации</a>
<a href="https://gamedev.ru/projects/forum/" class="tool">Проекты</a>
<a href="https://gamedev.ru/forum/" class="tool">Форум</a>
<a href="https://gamedev.ru/job/forum/" class="tool">Работа</a>
<button type="button" data-script="Skif_Search" class="tool"><div class="lupa"></div>
</div>
<div id="search"></div>
<div id="enter-pos">
<button type="button" class="volume green enter" data-script="but_Modal" data-init-script="but_ModalInit">Войти</button>
<div id="modal" class="veil"><div id="modal_pos" class="bound"><div class="modal-content">
<div id="login"></div>
</div></div></div>
</div>
</div>
</div>
<div class="path"><div class="bound"><a href="https://gamedev.ru/code/" title="Программирование игр">Программирование</a><a href="https://gamedev.ru/code/articles/" title="Статьи">Статьи</a><a href="https://gamedev.ru/code/articles/?physics" title="Физика">Физика</a></div></div>
<div class="bound">
<article itemscope itemtype="http://schema.org/Article">
<h1 itemprop="name headline">Физика «на пальцах»: солверы физических движков</h1>
<link itemprop="mainEntityOfPage" href="https://gamedev.ru/code/articles/?id=4706">
Автор: <a href="https://gamedev.ru/users/?id=20946" title="Suslik: Александр Санников">Александр Санников</a>
Данная статья объясняет принципы работы солверов современных физических движков.
<a id="cut"></a>В этом очерке я постараюсь объяснить, как работают <a href="https://gamedev.ru/code/terms/Solver" title="Солвер (Solver)">солверы</a> современных на момент написания статьи <a href="https://gamedev.ru/code/terms/PhysicsEngine" title="Физический движок (Physics Engine)">движков игровой физики</a>: <a href="https://gamedev.ru/code/terms/PhysX" title="PhysX">PhysX</a>, <a href="https://gamedev.ru/code/terms/ODE" title="ODE: Open Dynamics Engine">ODE</a>, Bullet, Box2D. За строгой математикой любопытный читатель всегда может обратиться к многочисленным существующим пейперам, <a href="https://gamedev.ru/community/gd_physcomm/articles/?id=682">ссылки</a> на которые можно найти в нашем сообществе и лекции, <a href="https://gamedev.ru/community/gd_physcomm/articles/">прочитанные</a> в нём же. Я же постараюсь абстрагироваться от строгой математики и попытаюсь объяснить, как это работает, что же означает каждое действие солвера. В любом случае, понимая, как он работает, проще вести и диагностику и расширение функциональности, например, разработать новый, специфический тип джойнта. Также рекомендую к прочтению более обзорную <a href="https://gamedev.ru/community/gd_physcomm/articles/phys_engine_development">статью о разработке своего импульсного физического движка</a>.
<a href="https://gamedev.ru/code/articles/?id=4706#formulirovka_zadachi" title="Физика «на пальцах»: солверы физических движков: Формулировка задачи">Формулировка задачи</a> 
<a href="https://gamedev.ru/code/articles/?id=4706#opisanie_metoda_sequential_impul" title="Физика «на пальцах»: солверы физических движков: Описание метода Sequential Impulses">Описание метода Sequential Impulses</a> 
<a href="https://gamedev.ru/code/articles/?id=4706#warmstarting__goryachiy_start_" title="Физика «на пальцах»: солверы физических движков: Warmstarting (горячий старт)">Warmstarting (горячий старт)</a> 
<a href="https://gamedev.ru/code/articles/?id=4706#sluchay_uprugogo_soudareniya" title="Физика «на пальцах»: солверы физических движков: Случай упругого соударения">Случай упругого соударения</a> 
<a href="https://gamedev.ru/code/articles/?id=4706#usovershenstvovaniya_algoritma" title="Физика «на пальцах»: солверы физических движков: Усовершенствования алгоритма">Усовершенствования алгоритма</a> 
<a href="https://gamedev.ru/code/articles/?id=4706#pseudovelocities__psevdoskorosti" title="Физика «на пальцах»: солверы физических движков: Pseudovelocities (псевдоскорости)">Pseudovelocities (псевдоскорости)</a> 
<a href="https://gamedev.ru/code/articles/?id=4706&page=2#drugie_tipi_soedineniy__djoyntov" title="Физика «на пальцах»: солверы физических движков: Другие типы соединений (джойнтов)">Другие типы соединений (джойнтов)</a> 
<a href="https://gamedev.ru/code/articles/?id=4706&page=2#trenie" title="Физика «на пальцах»: солверы физических движков: Трение">Трение</a> 
<a href="https://gamedev.ru/code/articles/?id=4706&page=2#zaklyuchenie" title="Физика «на пальцах»: солверы физических движков: Заключение">Заключение</a> 
<a href="https://gamedev.ru/code/articles/?id=4706&page=2#kod" title="Физика «на пальцах»: солверы физических движков: Код">Код</a>
<h1 id="formulirovka_zadachi">Формулировка задачи</h1>
Прежде всего сформулируем в чём же состоит задача солвера. На входе у него есть особым образом заданные ограничения на движения тел, его задача состоит в том, чтобы воздействовать на тела таким образом, чтобы все эти ограничения не нарушались или нарушались как можно меньше.
К сожалению, солвер «понимает» далеко не любые типы ограничений, а только заданные особым образом — ограничивающие ровно одну степень свободы системы.
Вообще, количество степеней свободы системы — это минимальное количество действительных чисел, которым можно описать произвольное её мгновенное состояние. Например, для описания системы, состоящей из статического бокса достаточно шести чисел — трёх компонент вектора, определяющего положение его центра масс и ещё три — углы Эйлера, определяющие его ориентацию. Если система состоит из двух боксов, свободно находящихся в пространстве, степеней свободы у неё будет уже двенадцать — по шесть на каждый бокс. А если прислонить бокс одной гранью к бесконечной плоскости, степеней свободы будет всего три, так как его положение можно будет однозначно установить двумерными координатами точки на плоскости и ещё одну координату на угол поворота в этой же плоскости.
Так какие же степени свободы мы хотим ограничить, например, при столкновении двух тел? Рассмотрим простой случай, когда тела касаются в единственной точке point, тела взаимодействуют по нормали norm и «отскок» нулевой. Контакт будет считаться удовлетворённым, если проекция относительной скорости двух тел на нормаль контакта будет нулевой. Интуитивное объяснение - при столкновении тел их скорость меняется таким образом, что контактирующие точки перестают сближаться.
Рассмотрим на простом примере двух столкнувшихся шаров без учёта вращения:
 
 
скорость первого шара: body1->velocity,
 
скорость второго шара: body2->velocity,
 
относительная скорость в точке contact->point можно рассмотреть, например, в системе отсчёта второго шара, она будет равна:
<div class="overflow pre"><pre> //все операции гораздо удобнее проводить над векторами,
//а не над их отдельными компонентами
Vector3 relativeVelocity = body1->velocity - body2->velocity;</pre></div>а теперь просто выразим проекцию относительной скорости на нормаль контакта:
<div class="overflow pre"><pre> //* - скалярное произведение
float velocityProjection = relativeVelocity * contact->norm;</pre></div>Теперь, если мы потребуем от солвера, чтобы velocityProjection было равно нулю, мы тем самым ограничим одну степень свободы системы — движение тел вдоль нормали контакта. Важно понять, что, удовлетворив этому требованию, мы лишь запретим контактирующим телам пролезать всё глубже и глубже друг в друга, никак не разрешая коллизию в случае, если они пересеклись. О том, как разрешать именно взаимопроникновения, мы рассмотрим в разделе "Pseudovelocities", ниже.
Как же учесть угловую составляющую скорости? Из курса механики известно, что если тело вращается вокруг центра масс body->pos с угловой скоростью body->angularVelocity, то скорость его точки point можно выразить как
<div class="overflow pre"><pre> //^ - cross product, векторное произведение
Vector3 pointVelocity =
body->velocity + (point - body->pos) ^ body->angularVelocity;</pre></div>Таким образом распишем выражение для нашей ограниченной степени свободы с учётом угловой скорости:
<div class="overflow pre"><pre> Vector3 relativeVelocity =
body1->velocity + (contact->point - body1->pos) ^ body1->angularVelocity
- body2->velocity - (contact->point - body2->pos) ^ body2->angularVelocity
float velocityProjection = relativeVelocity * contact->norm;
//полагаем velocityProjection = 0</pre></div>Преобразуем, объединив в одно выражение:
<div class="overflow pre"><pre> float velocityProjection =
body1->velocity * contact->norm
+ ((contact->point - body1->pos) ^ body1->angularVelocity) * contact->norm
- body2->velocity * contact->norm
- ((contact->point - body2->pos) ^ body2->angularVelocity) * contact->norm;
//полагаем velocityProjection = 0</pre></div>Далее применяем нехитрое векторное преобразование (a ^ b) * c == (c ^ a) * b и ещё раз преобразуем формулу:
<div class="overflow pre"><pre> float velocityProjection =
contact->norm * body1->velocity
+ (contact->norm ^ (contact->point - body1->pos)) * body1->angularVelocity
- contact->norm * body2->velocity
- (contact->norm ^ (contact->point - body2->pos)) * body2->angularVelocity;
//полагаем velocityProjection = 0</pre></div>и замечаем, что эту формулу можно переписать в виде:
<div class="overflow pre"><pre> Vector3 n1 = contact->norm;
Vector3 w1 = (contact->norm ^ (contact->point - body1->pos));
Vector3 n2 = -contact->norm;
Vector3 w2 = -(contact->norm ^ (contact->point - body2->pos));
float velocityProjection =
n1 * body1->velocity + w1 * body1->angularVelocity
+ n2 * body2->velocity + w2 * body2->angularVelocity;</pre></div>То есть получается, что ограничение, вносимое в систему из двух тел контактом, можно описать четырьмя векторами: n1, w1, n2, w2. справедливости ради заметим, что записанные подряд координаты этих самых векторов образуют строку Той Самой Матрицы Якоби, или Якобиана
j = (n1, w1, n2, w2),
а ограничение можно описать как j * v = 0, где v - это вектор обобщённых скоростей:
v = (body1->velocity, body1->angularVelocity, body2->velocity, body2->angularVelocity)
<h1 id="opisanie_metoda_sequential_impul">Описание метода Sequential Impulses</h1>
Осталось всего-то ничего, понять, что нужно сделать с телами, чтобы этому самому velocityProjection = 0 удовлетворить. Другими словами - что должно произойти с контактирующими телами, чтобы они перестали друг в друга проникать? Продолжаем рассуждать из физических соображений:
Взаимодействие столкнувшихся тел осуществляется передачей импульса в направлении contact->norm некоторой амплитуды lambda к точке contact->point к первому телу и такого же импульса противоположенного направления второму телу. Другими словами, тела при столкновении обмениваются имульсом contact->norm * lambda. Работу солвера в случае одного контакта можно свести к нахождению этой самой лямбды.
Ещё немного книжной механики. Распишем, как изменится линейная и угловая скорость тела, если приложить к его точке point импульс в направлении norm и с модулем lambda:
 
 
линейная составляющая высчитывается просто: делением вектора импульса на массу тела. Масса каждого тела для удобства хранится инвертированная, body->invMass = 1.0f / body->mass;
<div class="overflow pre"><pre> Vector3 velocityAfterCollision =
body->velocity + norm * lambda * body->invMass;</pre></div>С угловой составляющей чуть сложнее. Для простоты положим, что эллипсоид инерции симметричен, выражен в шар, то есть задаётся единственным числом — моментом инерции вокруг произвольной оси, проходящей через центр масс тела. Нехилое допущение, но желающие без труда могут преобразовать формулу для произвольного тензора инерции.
 
Говоря простым языком, момент инерции в нашем случае - число, полностью аналогичное массе, только масса связывает силу с ускорением, а момент инерции связывает момент силы с угловым ускорением. Для тестовых расчётов момент инерции вполне можно брать порядка массы объекта, помноженной на квадрат его характерного размера(т.е. длины или, например, высоты). Если ошибиться в расчёте момента инерции раз в 10, то физика работать, просто несколько менее естественно, а неподготовленный глаз может и не заметить отличий. Момент инерции, как и в случае с массой, храним инвертированным: body->invInertia = 1.0f / body->inertia;
<div class="overflow pre"><pre> Vector3 angularVelocityAfterCollision = body->angularVelocity
+ ((norm * lambda) ^ (point - body->pos)) * body->invInertia;</pre></div>Почему мы храним инвертированную массу и инвертированный момент инерции? На самом деле просто для удобства задания бесконечных масс, если body->mass устремить в бесконечность, то body->invMass будет равна нулю. Поэтому вместо обработки бесконечных величин мы просто храним обратные, которые в этом случае равны нулю.
Что же замечаем? Изменения линейной и угловой скоростей можно выразить через те самые n1, w1, n2, w2:
<div class="overflow pre"><pre> float velocityProjection =
n1 * (body1->velocity + n1 * body1->invMass * lambda)
+ w1 * (body1->angularVelocity + w1 * body1->InvInertia * lambda)
+ n2 * (body2->velocity + n2 * body2->invMass * lambda)
+ w2 * (body2->angularVelocity + w2 * body2->InvInertia * lambda);</pre></div>Преобразуем, получаем:
<div class="overflow pre"><pre>float velocityProjection = n1 * body1->velocity + n2 * body2->velocity
+ w1 * body1->angularVelocity + w2 * body2->angularVelocity
+ (n1 * n1 * body1->invMass + w1 * w1 * body1->InvInertia
+ n2 * n2 * body2->invMass + w2 * w2 * body2->InvInertia) * lambda;</pre></div>Напомню, что контакт считается решённым, если velocityProjection обращается в ноль. Получаем легко решающееся уравнение:
<div class="overflow pre"><pre> float a = n1 * body1->velocity + n2 * body2->velocity
+ w1 * body1->angularVelocity
+ w2 * body2->angularVelocity;
float b = (n1 * n1 * body1->invMass
+ w1 * w1 * body1->InvInertia
+ n2 * n2 * body2->invMass
+ w2 * w2 * body2->InvInertia);
a + b * lambda = 0;</pre></div>Уравнение такое можно решить, очевидно: lambda = –a / b; таким образом мы нашли имульс, которым обмениваются тела при введении ограничения степени свободы (n1, w1, n2, w2). Важно отметить, что сила реакции опоры может быть направлена только от поверхности контакта, то есть никак не вовнутрь. Таким образом, если lambda получается отрицательной, это значит, что тела не расталкиваются, а слипаются. Этого допустить никак нельзя, и если в каком-то контактном джойнте(и вообще любом, где телам разрешено передавать импульс только в одном направлении), импульс(lambda) получается отрицательным, мы его просто обнуляем. Далее, применив этот импульс к обоим телам, находим корректированные скорости после контакта.
Если перед решением джойнта мы замечаем, что проекция относительной скорости тел в точке контакта на нормаль этого контакта уже положительная(физический смысл - тела разлетаются), то контакт заведомо можно пропустить, так как он уже считается решённым.
Вот, собственно, и все чудеса, такая нехитрая последовательность действий позволяет солверу удовлетворить одному ограничению степени свободы. В чём же тогда проблема? Не слишком-то это было трудно. А проблема, как нетрудно догадаться, в том, что ограничений таких мноого (по меньшей мере по одному на каждый контакт) и удовлетворить им нужно всем одновременно. Чтобы сделать это, нужно каким-то образом решить систему уравнений, состоящую из количества уравнений, равного количеству ограниченных степеней свободы. Обычно эта величина порядка нескольких тысяч. Большинство методов решения системы линейных уравнений работает за сложность порядка O(n3), что просто убило бы производительность, прямой подход «в лоб» применяется редко. Зато существуют итеративные методы, постепенно делающие решение всё более и более точным. Так получилось, что если решать полученную систему уравнений одним из таких методов, называемых Projected Gauss-Seidel Solver, PGS, то последовательность производимых при этом действий математически эквивалентна последовательному решению джойнтов, буквально как описывалось выше. Этот подход широко распространён и называется Sequential Impulses.
То есть, если мы будем просто решать ограниечение за ограничением, не обращая внимание, что оно, вообще говоря, может быть и не одно и будем делать это достаточно долго, то полученный результат будет сходиться к результату, как если бы их решали в системе. За строгими доказательствами — в другие источники, но, уж на слово поверьте, там действительно ничего слишком сложного.
<h1 id="warmstarting__goryachiy_start_">Warmstarting (горячий старт)</h1>
Существует множество эвристик, существенно улучшающих сходимость алгоритма Sequential Impulses. Одна из самых важных называется warmstarting, заключается в том, что мы ищем решение системы уравнений каждую итерацию процесса моделирования не с нуля, а используя результаты с предыдущего шага. Эвристика использует свойство так называемой временной когерентности (time coherence) — предполагается, что напряжения, действующие в ограничениях, меняются от кадра к кадру не слишком значительно.
На практике реализуется так:<ul><li>сначала применяем аккумулированные на прошлой итерации импульсы во всех ограничениях</li><li>продолжаем решать ограничения, как ни в чём не бывало находя импульсы lambda, и просто прибавляем их к аккумулированному значению.</li></ul>
при этом также немного меняется стратегия, по которой мы накладываем ограничения на величину передаваемого импульса. если в случае без warmstarting'а ограничение на то, что тела могут только разлетаться, не слипаясь, схематично выглядело так:
<div class="overflow pre"><pre>lambda = ComputeLambda();
if(lambda < 0.0f) return;
ApplyImpulse(lamda);</pre></div>
то с добавлением аккумулирования импульса, стратегия немного меняется:
<div class="overflow pre"><pre>lambda = ComputeLambda();
accumulatedImpulse += lambda.
if(accumulatedImpulse < 0.0f)
{
lambda += (0.0f - accumulatedImpulse);
accumulatedImpulse = 0.0f;
}
ApplyImpulse(lamda);</pre></div>
Физический смысл произошедшего в том, что мы теперь ограничиваем только накопленный импульс, а lambda считаем его изменением. и если мы видим, что какое-то изменение lambda сделало накопленный импульс отрицательным, мы урезаем это изменение таким образом, чтобы оно обращало накопленный импульс ровно в ноль.
Основная проблема такого подхода — определить, какой из контактов был и на прошлой итерации процесса моделирования, а какой появился только что. Выдвигаются особые требования к алгоритму определения столкновений и его косвенная связь с, казалось бы, независимым от него солвером.
<h1 id="sluchay_uprugogo_soudareniya">Случай упругого соударения</h1>
 
До этого момента рассматривался случай, когда контакт считался решённым, если относительная скорость тел в проекции на нормаль контакта равняется нулю, то есть, другими словами, случай неупругого соударения. Если представить себе два шарика, летящие навстречу друг другу, то после решения такого типа контакта, они будто слипаются. Алгоритм нетрудно модифицировать на случай упругого соударения. Введём коэффициент отскока bounce, который принимает значения от 0 до 1, при этом случаю абсолютно неупругого соударения соответствует bounce = 0, случаю абсолютно упругого - bounce = 1.
Далее вспомним, чему будет равняться скорость, если тела обменяются через данный контакт импульсом с модулем lambda:
<div class="overflow pre"><pre> float velocityProjection =
n1 * (body1->velocity + n1 * body1->invMass * lambda)
+ w1 * (body1->angularVelocity + w1 * body1->InvInertia * lambda)
+ n2 * (body2->velocity + n2 * body2->invMass * lambda)
+ w2 * (body2->angularVelocity + w2 * body2->InvInertia * lambda);</pre></div>Если в случае с абсолютно неупругим соударением мы ставили условие velocityProjection >= 0. Теперь поставим условие следующим образом: velocityProjection = -bounce * initialVelocityProjection. Здесь initialVelocityProjection - величина, равная:
<div class="overflow pre"><pre> float initialVelocityProjection =
n1 * body1->velocity
+ w1 * body1->angularVelocity
+ n2 * body2->velocity
+ w2 * body2->angularVelocity;</pre></div>
Чтобы понять, что это значит, вернёмся к аналогии с двумя сталкивающимися шариками. То есть мы хотим, чтобы при bounce = 1 тела после решения контакта начали бы отдаляться с такой же скоростью, с какой они до его решения сближались, а при bounce = 0, чтобы они относительно друг друга остановились. В остальном алгоритм решения каждого контакта остаётся практически без изменений:
 
1) Считаем величину b, которая является коэффициентом при lambda и зависит от нормали, точки контакта, массы и момента инерции каждого из тел. Формула для неё остаётся той же самой.
 
2) Считаем велиичну a, которая зависит от скоростей контактирующих тел и всё тех же параметров контакта. Теперь, когда мы ввели коэффициент bounce, принимает такой вид:
<div class="overflow pre"><pre> float a = (n1 * body1->velocity + n2 * body2->velocity
+ w1 * body1->angularVelocity
+ w2 * body2->angularVelocity) + bounce * initialVelocityProjection;</pre></div>
Выражение для initialVelocityProjecton - выше.
 
3) находим lambda = -a / b;
 
4) применяем lambda к обоим телам.
Важно отметить, что если используется несколько итераций солвера, то математически корректно будет сначала посчитать для каждого контакта initialVelocityProjection, а потом прогонять несколько итераций солвера, не изменяя это значение. 
<h1 id="usovershenstvovaniya_algoritma">Усовершенствования алгоритма</h1>
Приведённая последовательность действий лишь частично предотвратит взаимопроникновение тел. К сожалению, из-за ошибок интегрирования и итеративного не совсем точного решения системы, тела всё-таки будут частично проникать друг в друга, это может быть особенно заметно, если на тела продолжительно действует сближающая их сила. Простейший случай: бокс, стоящий на столе, при таком подходе будет постепенно в него погружаться. Чтобы предотвратить это явление, существует ряд методик. Одна из самых простых называется velocity-based, основана на том, что мы считаем контакт решённым не при условии velocityProjection >= c а при модифицированном: velocityProjection >= c + contact->depth * ERP.
<a href="https://gamedev.ru/code/terms/ERP" title="ERP: Error Reduction Parameter">ERP</a> (error reduction parameter) играет роль чего-то вроде архимедовой силы — чем глубже тела проникают друг в друга, тем быстрее мы хотим, чтобы они искусственно расталкивались. физическая аналогия: что-то в духе архимедовой силы, выталкивающей пенопласт из воды. Грубоватая, правда, аналогия, потому что, во-первых, архимедова сила зависит от объёма погружённой в жидкость части тела (мы учитываем глубину), и архимедова сила влияет на ускорение, а мы воздействуем напрямую на скорость.
К сожалению, это простой, но не слишком эффективный подход, из-за него глубоко проникшее тело «выплёвывается» из того, в которое оно проникло и может неестественно далеко улететь. Куда более практичный подход — использование так называемых псевдоимпульсов и псевдоскоростей:
<h1 id="pseudovelocities__psevdoskorosti">Pseudovelocities (псевдоскорости)</h1>
Псевдоскорость — искусственно введённый в систему параметр, служащий для расталкивания тел. В случае контакта, вместо использования одного уравнения мы поступаем следующим образом:
 
 
1) составляем как описывалось выше систему контактов без velocity-based добавки:
 
velocityProjection >= c;
 
2) решаем, как ни в чём не бывало.
 
3) обнуляем псевдоскорости всех тел.
 
4) составляем ещё одну систему, на этот раз не для скоростей, а для псевдоскоростей:
 
pseudoVelocityProjection >= contact->depth * ERP;
 
5) решаем в точности таким же подходом систему для псевдоскоростей, предполагая, что это настоящие скорости тел.
 
6) интегрируем движение каждого тела для обычных скоростей по закону
 
velocity += acceleration * timeStep; pos += velocity * timeStep;
 
7) интегрируем движение каждого тела для псевдоскоростей по закону
 
pos += pseudoVelocity * timeStep;
Физический смысл подхода не слишком прозрачен, но состоит примерно в том, что мы наделяем тела дополнительными мгновенными скоростями, которые обнуляются, как только тела расталкиваются друг из друга. В результате чего они раздвигаются, но не разлетаются. Вообще говоря, они обнуляются каждый кадр, а не только в момент, когда одно тело вытолкнется из другого, но сути это не меняет. Хочется отметить, что попытки ввести в систему для псевдоскоростей warmstarting добром редко увенчиваются, потому что система и без него сходится достаточно быстро, а стабильность warmstarting понижает значительно. Это обозначает, что warmastarting имеет смысл применять для обычной системы импульсов, а систему для псевдоскоростей решать каждый кадр заново, без warmstarting'а.
<div class="pages">Страницы: 1 <a href="https://gamedev.ru/code/articles/?id=4706&page=2">2</a> <a href="https://gamedev.ru/code/articles/?id=4706&page=2">Следующая »</a></div>
 <a href="https://gamedev.ru/code/articles/tags/gauss-seidel">#gauss-seidel</a>, <a href="https://gamedev.ru/code/articles/tags/pgs">#pgs</a>, <a href="https://gamedev.ru/code/articles/tags/основы">#основы</a>, <a href="https://gamedev.ru/code/articles/tags/солверы">#солверы</a>
<meta itemprop="datePublished" content="2010-01-5">5 января 2010
(Обновление: 9 авг 2020)
<a href="https://gamedev.ru/code/forum/?id=127872">Комментарии</a> [<a href="https://gamedev.ru/code/forum/?id=127872&page=43#m644">644</a>]
<div itemprop="publisher" itemscope itemtype="http://schema.org/Organization"><meta itemprop="name" content="GameDev.ru" /></div>
</article>
<div class="seo"><script type="text/javascript">
<!--
var _acic={dataProvider:10};(function(){var e=document.createElement("script");e.type="text/javascript";e.async=true;e.src="https://www.acint.net/aci.js";var t=document.getElementsByTagName("script")[0];t.parentNode.insertBefore(e,t)})()
//-->
</script><style type='text/css'> .block_links * { background:transparent none repeat scroll 0 0 !important; border:medium none !important; clear:none !important; clip:rect(auto, auto, auto, auto) !important; font-size:100% !important; font-style:normal !important; font-variant:normal !important; font-weight:normal !important; height:auto !important; letter-spacing:normal !important; line-height:normal !important; margin:0 !important; overflow:visible !important; padding:0 !important; position:static !important; text-align:left !important; text-decoration:none !important; text-indent:0 !important; text-transform:none !important; vertical-align:baseline !important; visibility:visible !important; white-space:normal !important; width:auto; word-spacing:normal !important; z-index:auto !important; cursor: pointer!important; word-wrap: break-word!important; } .block_links li { display:list-item !important; list-style-image:none !important; list-style-position:outside !important; list-style-type:none !important; display: inline; } .block_links li DIV { padding:0.5em !important; } .block_links DIV, .block_links TABLE { padding: 5px !important; } .block_links { width: auto!important; font-family: Verdana!important; font-size: 11px!important; border: 1px solid #DDDDDD!important; background-color: #dedede!important; padding:5px!important; position: relative!important; display:block!important; -webkit-border-radius:5px !important; -khtml-border-radius:5px !important; -moz-border-radius:5px !important; border-radius:5px !important; } .block_links_icnt, .block_links_icnt * { text-align: left!important; } .block_links_text, .block_links_text A, .block_links_text A:hover { color: #808080!important; font-size: 11px!important; text-decoration: none!important; } .block_links_url { color: #808080!important; font-size: 11px!important; text-decoration: none!important; } .block_links_header, .block_links_header A { color: #808080!important; font-size: 13px!important; font-weight: bold!important; text-decoration: underline!important; } .block_links_sign { color: #999999!important; font-size: 10px!important; text-align: left!important; text-decoration: none!important; } .block_links_clear { clear:both!important; } .block_links TABLE { width: 100%!important; border: 0px!important; } </style><div class='block_links' > <table> <tr> <td class='block_links_icnt' style='width:100%'> Скачать игры и моды на Андроид <a href="http://droid-mobile.ru/" target="_blank">Скачать игры и моды на Андроид</a> droid-mobile.ru </td> </tr> </table></div></div>
</div>
<div class="footer"><div class="bound">
<div class="footblock r right text">
<button type="button" data-link="https://vk.com/gamedev_ru" title="vk.com"><div class="vk"></button>
<button type="button" data-link="https://twitter.com/ru_gamedev" title="twitter"><div class="twitter"></button>
<div style="padding-top: 15px;">
<a href="https://gamedev.ru/members/" class="gray">Участники</a>
<a class="g" href="https://gamedev.ru/help/donate" class="gray">Donate!</a>
</div>
</div>
<div class="footblock text">
<a href="https://gamedev.ru/?info" class="gray">Контакт</a>
<a href="https://gamedev.ru/community/" class="gray">Сообщества</a>
<a href="https://gamedev.ru/top/" class="gray">Каталог сайтов</a>
<a href="https://gamedev.ru/tags/" class="gray">Категории</a>
<a href="https://gamedev.ru/news/?adoc=arch" class="gray">Архив новостей</a>
</div>
<div class="center q">GameDev.ru — Разработка игр ©2001—2024</div>
</div></div>
<script><!--
skif.run();
//-->
</script>
</body>
</html>

Home · About · News · Docs · Terms