Войти
ПрограммированиеФорумФизика

Вопросы по написанию физического движка

#0
16:04, 3 июня 2022

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

  1)считаем скорости
  2)определяем коллизии
  3)солвер решает ограничения и обновляет скорости
  4)обновляем трансформацию
  5)рисуем

Или нет?

#1
18:01, 3 июня 2022

Featherstone's algorithm
Baraff
Mirtich

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

https://github.com/RandyGaul/ImpulseEngine

#2
19:55, 3 июня 2022

Движок Randy Gaul я пропустил - код простой, должен на многие вопросы ответить, спасиба.
Но в плане цикла физдвижка он только сбил с толку - он вычисляет скорости до солвера, причем на пол dt, а потом еще после солвера и после вычисления трансформаций еще раз вычисляет скорости на пол dt - это зачем?

#3
20:18, 3 июня 2022

В NZ сейчас 05:18 утра. Если что.

#4
22:22, 3 июня 2022

MaRC
> это зачем?
Если шаг физики не постоянный, то именно так выглядит схема повышенного порядка точности.
Но обычно лучше шаг сделать фиксированным и эти полушаги слить.

#5
14:01, 4 июня 2022

MaRC
>   1)считаем скорости
>   2)определяем коллизии
>   3)солвер решает ограничения и обновляет скорости
>   4)обновляем трансформацию
>   5)рисуем
можно считать в любом порядке и оно сойдётся к правильному результату при устремлении шага интегрирования к нулю. но разный порядок может давать немного разную устойчивость и немного разную скорость сходимости. апдейт в два полушага эквивалентен какому-то из методов рунге-кутта : https://en.wikipedia.org/wiki/Runge%E2%80%93Kutta_methods

#6
22:42, 4 июня 2022

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

Статью Суслика на гидру, естественно, знаю :)

#7
11:53, 6 июня 2022

https://dyn4j.org/2011/11/contact-points-using-clipping/
https://erikonarheim.com/posts/understanding-collision-constraint-solvers/
http://allenchou.net/game-physics-series/
http://www.randygaul.net/2013/03/27/game-physics-engine-part-1-im… e-resolution/
Вообще в поиске что то типа physics contact solver и collision contact manifold  и там в основном эти несколько фамилий и будут Dirk Gregorius, Randy Gaul, Erin Catto, Erwin Coumans - те кто игровой физикой занимались. Ну и Suslik само собой.
Пишешь движок, попутно по кругу читаешь статьи авторов, иногда заглядывая в код бокс2д лайт и простого движка Ренди и постепенно приходит понимание и просветление:)

#8
12:30, 6 июня 2022

MaRC
>Пишешь движок, попутно по кругу читаешь статьи авторов, иногда заглядывая в код бокс2д лайт и простого движка Ренди и постепенно приходит понимание и просветление:)

А на игру ни сил, ни свободной памяти уже не остаётся. Специализация.

#9
12:38, 6 июня 2022

Skvoznjak
> А на игру ни сил, ни свободной памяти уже не остаётся. Специализация.
Физических движков на рынке сейчас куча, не идеальные, но сам ты в при любом раскладе лучше не напишешь в обозримом будущем.
Писать свой движок нужно для самообразования, чтобы чужие движки использовать не как черную коробку, а понимая, что у них под капотом и почему они так работают.
Если ты с физикой и математикой на ты, то минимальный простенький движок за неделю пишется. Просто силы, скорости, минимальные коллизии - чисто разобраться в теме, а потом забыть о самописном и уже осмысленно пользоваться чужим, на написание которого ушли годы.

#10
13:51, 6 июня 2022

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

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

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

Это просто интерес именно к этой части игрового движка. Хочется тебе разобраться с вопросом и разбираешься. Не нужно придумывать оправдания - если интересно, то разбирайся, а чтобы разобраться, проще всего свою версию замутить. Физика тут вообще почти не при чём, потому что с хорошей физикой изделие ни один доступный комп не потянет. Вот тебе простой пример. Фпс за 400, видимых тормозов нет, в отрезке 100мс запланирован какой-то манёвр, а он по логике никогда не случается, сразу происходит следующий. А всё потому, что в этот момент в другом потоке подгружается контент с диска и что-то с ним делается, а в этом потоке из-за этого происходит торможение  в течении ~200мс, фпс не страдает, но некоторые действия "съедаются". Где в реальной физике есть такие эффекты по типу миллиард китайцев на праздник синхронно захлопали в ладошки, а ты от этого в прыжке подзавис или движение пропустил, сразу к следующему перешёл. В игре физика наложена рваной тонкой плёнкой на мешанину кишок и шестерёнок как локальная иллюзия, а в реальности - простирается далеко и глубоко. По типу игровой физики японцы реальное изделие патчили, когда заклеивали трещины в АЭС скотчем с нарисованной текстурой бетона - налепили плёнку и всё красиво.

#11
14:18, 6 июня 2022

Skvoznjak
> Это понимание понадобится если подключенный движок чем-то не устраивает и его
> нужно пропатчить или переписать изменив кодовую базу.
Готовый движок, который писался много лет и на мильярд строк кода нифига ты не пропатчишь, там черт ногу сломит. Да и за эти же много лет там все пропатчено до тебя.
При работе с физдвижком намного проще и эффективнее, когда ты понимаешь, как работают Joint'ы, как строятся контакты при коллизиях и т.д.  Про support mapping как бы я еще узнал. Поэтому свой простой движок желательно набросать.

#12
16:07, 6 июня 2022

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

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

#13
13:57, 15 июня 2022

Вродь все, кроме трения написал и выглядит оно правдеподобно.
Вопросы по точкам контакта.
Еще много лет назад, когда пробовал глянуть точки контакта в Unity, мне они не показались логичными. Сейчас, когда вник в тему и стало понятно, почему выбирают именно их, но все равно подход вызывает какоето внутреннее отторжение. Или я что-то упускаю?
Точки контакта лежат либо на поверхности incident face, либо проецируем их на плоскость reference face, но какой подход мы бы не выбрали, при смене местами incident и reference face нормаль и длина проникновения изменятся не сильно, а точки контакта могут изменится значительно.
Изображение
На картинке верхний кубик наклонился вправо - точки контакта на его фейсе, наклонился влево - точки контакта уже на фейсе нижнего кубика.
По сути в первом случае мы определяем, насколько верхний кубик проник в нижний, а во втором - насколько нижний проник в верхний. Если посчитать оба этих проникновения сразу и взять за точки контакта среднее между ними не улучшаться ли тогда штуки типа warmstarting'a?

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

ПрограммированиеФорумФизика

Тема в архиве.