вот коммит целиком, со всем выводом GPT: https://github.com/zenkovich/o2/commit/a1092d1a60b93d9df042b5ce60a61fdf9a2f3abd

остается понять, какую часть я смогу себе реально взять. Это сложно, потому что мне так же рутинно нужно все посмотреть

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

сегодня попробуем достать тему из закромов - про физику в играх.

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

Все это писал сам, в основном по сторонним туториалам, ибо тогда мозгов было маловато чтобы до всего допереть самому. Например, как этот чел с gamedev.ru

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

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

Но вся иллюзия быстро рассыпается когда эта картинка начинает двигаться. Даже не так, какие-то "твердые" вещи в играх выглядят весьма правдоподобно - дома, машины, роботы и тд. Но персонажи, разрушения - это прям беда. А наш мозг очень сложно обмануть, он подмечает самые мельчайшие детали. И пусть даже словами сложно сказать что не так, то мозг быстро отличает фейковую картинку от настоящей. Особенно это заметно на всяких лицевых анимациях. Будем честны, технологии шагают вперед, но как были резиновые рожи в играх так они и остались. Они не выглядят естественными и правдоподобными. Они выглядят "окей", чего вроде бы достаточно. Единственный пример обратного, который я могу привести - это Hellblade: Senua's Sacrifice. Там лицевая анимация просто топ, имхо это должно стать стандартом индустрии

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

Еще пару моих любимых примеров качественной физики: всем известный beam.ng и малоизвестные мододелы для besiege. Здесь учтены те самые детали, которые сложно описать словами, но легко заметить глазу.

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

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

Итак, как же оно устроено внутри в игровых движках? А точнее физических

Первое с чего нужно начать - это дискретность. В отличии от реальной жизни, на компьютере нам приходится считать физику по кадрам. То есть раз в какой-то короткий промежуток времени (1/60 секунды обычно) тела замирают, происходит пересчет точек контакта, взаимодействующие силы, и затем 1/60 секунды тела летят по своим направлениям как будто ничего нет. Снова останавливаются, все пересчитывается и они снова летят

И в этом огромны геморрой

Казалось бы 1/60 секунды - достаточно малый промежуток времени. Но не в физике... За это время может произойти многое. Как правило это связано с большими силами, и, как следствие, большими скоростями. Тела проникают слишком глубоко, или вовсе друг через друга. Классический пример: пуля, летящая через тонкую стенку. Один кадр она с одной стороны стены, следующий кадр - с другой. И никакого контакта между ними не было

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

Но базово это работает всегда так - раз в какое-то время все замирает, обсчитывается и 1/60 секунды летит как получилось.

Теперь, какие подходы в физике игр вообще бывают. Их есть целых две штуки:
- физика твердых тел
- физика мягких тел (или иногда называют физика верле)

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

Физика твердых тел

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

Начнем с общего описания твердого тела (rigid body):
- трансформация. Матрица (или вектор + кватернион) описывающие положение и поворот тела в пространстве
- масса. Сколько весит тело в килограммах
- линейная и угловая скорости. Два вектора, показывающие в какую сторону и скакой скоростью летит/крутится тело
- инерция тела / момент инерции. Параметры, показывающий насколько сильно тело сопротивляется внешней силе, пытающейся его сдвинуть с места или закрутить

С помощью этих параметров можно интегрировать тело - оно имеет положение в мире, может двигаться, к нему можно прикладывать силу. Кстати, о силах

Физика твердого тела оперирует импульсами - это сила, приложенная в течении какого-то времени. Тела при столкновении обмениваются импульсами. Они заставляют их отталкиваться друг от друга или останавливать.

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

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

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

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

Какие есть подходы к широкой фазе? Самый примитивный - bounding box. Каждое тело описывается крайне простой оболочкой, которую легко проверять на пересечение, и в которую полностью вписывается реальная. более меньшая и точная геометрия. Для таких целей подходит axis aligned bounding box (AABB) или сферы. AABB - это прямоугольник, выровненный по осям. То есть для проверки пересечения двух AABB применяются довольно простые формулы:
- if (one.right < second.left one.left > second.right one.top < second.bottom || one.bottom > second.top) return false;

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

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