Russian Qt Forum

Добрый день

Заколебали все эти примочки с юником и шаредом, хочется поговорить о большом и светлом :)

Пусть мы освоили "современные технологии" и интегрировали движок Bullet в приложение. Теперь мы можем создать напр 100 шариков которые падают на плоскость (переписать пример). Теперь мы хотим чтобы они как-то двигались (или катились) в заданном направлении, напр по оси X, т.е. слева направо. Для этого есть штатное средство движка - сила. Нужно просто позвать (псевдокод)

C++ (Qt)
void rigidBody::ApplyForce( const vector & force );
 

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

Очевидно надо создать такой объект "сила" в нашем приложении и дать юзеру возможность им управлять во времени. Как это сделать? Какими должны быть параметры объекта "сила"?

Из школьного курса помнится формула
Ну масса (m) - это свойство объекта, для простоты считаем m = 1. Значит объект "сила" должен иметь параметр "acceleration". Вроде все ясно, но увы, это работает плохо. Да, объекты движутся, но

1) Время разгона часто слишком велико. Правду сказать, физику я никогда особо не понимал. Тот еще пример: вот человек держит тяжелый мешок, выбивается из сил, но... оказывается "с точки зрения физики" никакой работы не выполняется! Какая-то подозрительная точка зрения :'( Подобное и здесь. Ну вот стоял человек, а потом взял и пошел - разве мы видим какую-то "фазу ускорения"? (я нет)

2) Наоборот, когда объект разогнался, то остановить (или даже замедлить) его - капитальный гемор. Просто так поставить acceleration = 0 (в нужный момент) не выходит, это просто "больше не ускорять", но текущая скорость-то остается. Приходится как-то прилагать силу в противоположном напр-и и.т.д.

3) По сути та же проблема c поворотом. Да, можно изменить вектор силы, но опять-таки старая скорость остается, поворот получается по какой-то параболе.

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

Какие решения Вы можете предложить? Какие параметры должен видеть юзверь в UI объекта "force" ?

Спасибо

Здесь системы диффуров в помощь.. :) И их решение методами Эйлера или Рунге-Кута 4-го порядка (все что помню из курсов в универе)..

Ну я чуть больше (ненамного, жизнь заставила). Эйлер совал свой пятак в очень многие вещи, поэтому под "методом Эйлера" обычно понимается не какие-то заумные формулы, а чисто алгоритм, примерно

- делаем "шаг" по времени, он должен быть достаточно мал. Выполняем действия шага, напр двигаем объекты, обычно с линейной скоростью

- проверяем "граничные условия", напр пересекаются ли объекты? Если нет - принимаем сделанный шаг и переходим к следующему. Иначе откатываемся и уменьшаем шаг

И собсно с Эйлером все. Так (в общих чертах) движок находит момент когда объекты пересеклись, но еще не "залезли друг в друга". Обнаружив это, движок собирает "контактные пары" и на их основании вычисляет взаимодействие объектов, напр отскок. Т.е. "в общих чертах" (если не копать детали) все довольно просто, и никакими "дифурами" там и не пахнет, их усердное изучение в ВУЗе носит чисто ритуальный характер  :)

Ну и в данной теме это все ни причем. Что делать с этим Ньютоном который на практике не работает ?  :'(

V = a*t, a = V\t.

Хотите остановить мгновенно (t = 0.0000001), примените очень большую обратную силу (ускорение).

А "интерактивности" нет, это не игра. Юзер может управлять силой во времени, но не объектом/симуляцией напрямую. Напр ускорение -30*100 может и остановит объект со скоростью 100 в течение одного кадра (30 fps), Но может и нет, если объект "уперся лбом" в стену, то его скорость уже = 0, и отрицательное ускорение толкнет его назад.

Поэтому нужно разумное/умелое управление вместо головняка с "голым" Ньютоном.

На всякий случай разжуем

"Интерактивно" - по-простому "давлю клавиши", нужно быстрее - нажал стрелку вперед, тормоз - стрелку назад и.т.п. Здесь никаких проблем не возникает, по Ньютону вполне достаточно.

Однако вот напр идет группа товарищей (https://dropmefiles.com/gbyKt) (35 метров, скрыншот ниже), управлять каждым не хватит клавиш и/или рук. В играх это иногда называют "NPC", т.е. монстры которыми игрок не управляет, но которые тоже "ходют". Вот мы запускаем движок и сообщаем ему что есть Force действующая на N заданных объектов. Да, юзер может управлять параметрами силы во времени. Напр задать acceleration = 100 для кадров 0-50 и acceleration = -100 для кадров 50-100 и.т.п. И это будет скармливаться движку. Однако это не интерактивно, т.е. какую скорость имеют объекты в момент приложения силы - известно приложению/коду, но не юзеру, он ее сможет узнать только после того как движок отработает и рез-т записан (все свершилось, управлять нечем). Поэтому просто "менять ускорение" не выходит

Ну вот, стесняются товарищи :) Видимо смущает бедноватый багаж, ну в самом деле
И это.. все формулы ??? Ну как-то это совсем не похоже на "современные технологии" и совсем не круто. Должна (обязательно) быть какая-то вумная "фишка", и вот тогда, зная ее... А так не, ну это несерьезно  :)

А между тем разумные ответы были, и не один. Ну хотя бы

1) Чисто "шкурный" подход. Bullet - пожалуй самый популярный движок физики, и эти "силы" должны применять многие. Без них (вернее с одной гравитацией, это тоже сила) можно сыпать объекты на плоскость, этого вдоволь наелись еще в начале нулевых. Так как делают другие?

2) Хотя в стартовом посте и не звучало, но в первую очередь надо ограничить скорость объекта, не может она расти бесконечно, хоть в играх, хоть в real-life, хоть где. Вот и параметр для юзверя "Max Speed", может с чекбоксом

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

Мда... ну ладно  :)

Изменение импульса тела обусловленно действием на него силы. Так что пока на тело будет действовать сила, оно будет двигаться с ускорением.
Хотите равномерного движения, с возможностью управлять величиной скорости: бейте по телу кратковременной (tau - время действия силы) силой F.
Тогда, если скорость в начальный момент была v₀, то после времени tau, тело будет двигаться с постоянной скоростью v = v₀ + F*tau/m.  

Жирным шрифтом выделены вектора.

Igors. По-поводу движка не знаю, а по-поводу Ньютона можно сказать так. В момент остановки и отскока, да, действуют силы и F = ma. Но силы эти кратковременны, велики и изменяются по трудно учитываемым законам. Для проверки попробуйте ударится головой о стену :) Поэтому при исследовании удара применяются другие законы (которые есть следствия F = ma, но это неважно) Это сохранение энергии для абсолютно упругого удара mv²/2 = const и то, что изменение скорости происходит по нормали к поверхности столкновения. Если удар не абсолютно упруг, часть энергии (или даже вся) теряется на деформацию-нагревание поверхностей. И вот для удара или внезапной остановки (что по сути тоже есть удар, как и внезапное начало движения) в движке должны присутствовать именно эти формулы.
То есть, для вычисления ситуации на следующем такте игры надо использовать именно формулы, придуманные для анализа удара.
Уточню еще (из физики). В самом деле момента удара не существует. Удар - это тоже процесс во времени. Но время мало, а силы не поддаются простому вычислению (если не привлекать физику твердого тела) Поэтому мы связываем два состояния "до" и "после" другими уравнениями.
Конечно, если шариком является чья-то голова, этот подход несколько бесчеловечен. При ударе о деревянную и бетонную стену в этой голове будут происходить разные эффекты. Но для внешнего наблюдателя эта разница не имеет никакого значения. :)

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

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

 
И здесь оказывается, что пользователю не поведением каких либо бездушных тел нужно управлять, а группой "товарищей"  ;) :D

Так вот "товарищи" сами по себе обладают поведением и возможностями прикладывать к себе силы по мере необходиомости для достижения поставленных целей. Применение к ним модели сил со стороны пользователя выглядит весьма странно - как некое божественное вмешательство).

Обычно, для "товарищей" реализуется индивидуальная модель поведения с заданными ограничениями (скорость, ускорение и т.п.), а пользователем задаются параметры для реализации этой модели. Например, двигаться в из точки А в точку Б с 50% от физических возможностей "товарища", чтобы не сильно устать)), или не много топлива потратить, или других ресурсов, расход которых определяется моделью поведения.

Именно это и делает игрок постоянно "подправляя" поведение клавишами, но, как жевали выше, такой возможности здесь нет. Как всегда, Вы пропустили постановку мимо ушей  :'(

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

Но я же не хотел (или не спрашивал) как управлять соударениями :) Возьмем "элементарный" (как говорят пижоны) пример - кубики падают на плоскость, таких демок полно. Очевидно рулит сила гравитации, при этом контакты, отскоки и.т.п. - все есть, никто не отменял. Добавляем еще силу, напр вектор X. Да, она будет двигать объекты, но управлять ей чертовски неудобно (список оглашен выше). Вот о чем речь, на лавры  сэра Исаака никто не претендовал  :)

Неужели "начало доходить"?  :)

На мой взгляд короче и яснее сказать: "монстры должны управляться скриптами". С этим трудно не согласиться, но если прикинуть сколько "еще всего" надо для этого - сразу плохеет. Нужен механизм событий, нужны (долбаные) графы поведения и еще бог весть что. Да, и "монстры" - просто удачный пример, никакой игры нет, душный или бездушный объект - дело юзера, могут быть просто летающие шарики. И, кстати, опыт внедрения пытона показал - да, есть юзеры для которых скрыпты в кайф.  Но увы, их подавляющее меньшинство, обычный ответ "I'm not a programmer" что по сути = "а не пошел бы ты со своими скриптами.." в вежливой форме.

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

Это другая, еще более интересная тема. А насколько "физически корректно" Вы (я, он) ходите? Если призадумаетесь, то очень скоро Вы обнаружите что от физики там остаются "рожки да ножки". Если отдать движку "просто модель (человека)" то ни одного "физического" шага эта модель не сделает, сразу рухнет. И то если движок не захлебнется на decomposition. Причем "корректно упасть" - своя, не слабая задача. Как уже упоминалось, мы почему-то обычно не видим плавного ускорения/останова. И физика ничего не знает о том что человек обычно ходит "лицом вперед". А "подъем по ступенькам" - еще одна прелесть. И много еще чего. И все это мне надо делать - но я совсем не знаю как :) Ну разумеется "открыть книгу" как всегда (мягко говоря) "не катит". Поэтому с удовольствием поговорю на эту тему

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

Управляете, например, автомобилем, Вы ведь силы не задаете? Руль крутите и педали жмете в зависимости от текущих характеристик движения.


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

Bullet умеет управлять автомобилями :) Однако это специфическая симуляция за рамками данной темы

"Нужный момент" - это "событие" которое надо иметь, о чем я говорил. А так не вижу принципиальной разницы между "моделью поведения" и "объектом силой". Ну вот напр есть сила "движение по заданному пути", там вместо вектора напр-я задается путь который может быть сколь угодно кривым и иметь "толщину". Вот Вам и "модель" если без этого уж никак нельзя. Только это ничего не меняет, все равно силы надо как-то считать, а инерцию как-то гасить. Просьба держаться ближе к этой (изначальной) теме

На пальцах попробую передать мысль)
Есть два вида объектов безвольные (с отсутствующей внутренней моделью поведения) и своевольные (у которых есть внутренняя модель поведения).
На первые действие оказывается только с помощью внешнего воздействия - применения сил и др.
Вторые к внешнему воздействию могут добавить внутреннее. То есть если что-то должно самостоятельно двигаться по кругу, то пусть оно и старается двигаться).
Если самостоятельное движение должно быть на что-то похоже, то это "похоже" нужно представить в виде внутренней модели, которая управляться может какими-то параметрами (специфичными для данной модели). Суперпозиция внешнего воздействия с внутренним и даст желаемое поведение.

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

Надеюсь я Вас понял. Придать char'у некоторое специфическое/индивидуальное поведение - это конечно интересно. Но сейчас речь идет о самой базовой, "рудиментарной" работе с движком. Есть текущий вектор силы - и в данной теме совершенно не волнует как его посчитали, неважно что там привлекалось для его расчета. Главное он посчитан и известен. Кроме него известна текущая (реальная) скорость объекта и крутящий момент. Теперь надо скормить эту силу движку так чтобы юзер получил удобное, предсказуемое поведение (а не ту фигню что придумал Ньютон). Разумеется юзера интересует скорость, поэтому давать какие-то установки скорости в UI не запрещено. Но менять скорость для движка напрямую низзя, как уже говорилось, потеряем физику.

Вот траектории движения с поворотом (аттач). Юзер совсем не возражает против левой и средней картинок, наоборот, ясно что какая-то (регулируемая) плавность/радиус нужны. Но "чисто по Ньютону" получается правая картинка - старая/имеющаяся скорость никак не гасится. Люди так не ездиют! Приложить силу в обратном направлении.. ну что это трудно сделать из UI уже говорилось, но это и по смыслу неверно - необязательно велосипедист тормозит на повороте, но всегда поворачивает руль (меняет вектор силы)

Так как бум гасить?

Если всё происходит в невесомости в открытом космосе, то именно правый вариант является правильным.)

А так велосипедист имеет еще сопряжение с дорожным покрытием, относительно которого как минимум действует сила трения (качения или скольжения), зависящая от кучи разных характеристик (скорость движения, коэффициент сцепления и т.п.). При этом у велосипеда обычно два колеса, каждое из которых скользит и катится по разному. А если велосипедист ухватится еще за точку опоры для поворота? И т.д. ;) И опять же ветер в лицо дует, значит есть ещё сила сопротивления и т.д.

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

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

Интересно Вы мыслите), но неверно.
Если велосипедист не затормозит на повороте - улетит в кювет), что и бывает с автомобилями в реальной жизни при гололёде.
Поворотом руля, нажатием на тормоз велосипедист как раз управляет силой сопротивления за счет трения, которая зависит кроме всего прочего от ширины соприкосновения поверхностей вдоль направления движения. Точно также конькобежец управляет скоростью и направлением движения только за счет поворота лезвия конька.

Утверждение "неверно" подразумевает что верный ответ/решение известно. Но я в упор его не вижу в Ваших постах :) Где Вы просто перечисляете все что Вам известно даже не пытаясь делать никаких выводов. Да, все что Вы сказали разумно, но .. из этого ровным счетом ничего не следует, и как решать - хз.  Немудрено что сваливаемся в обычное "лапки кверху", мол, да пусть этим физики занимаются (а мы продолжим лакать std::move и.т.п.)

Попробуем подойти более конкретно, разберемся почему в жизни велик едет как на средней картинке. Вот аттач, вертикальный (черный) вектор - начальная скорость, и вот теперь повернули руль по направлению зеленого вектора. Разложим черный вектор на 2 компоненты. На зеленую действует лишь небольшая сила трения (качения). А вот синий попадает под раздачу, на него действует мощная сила трения скольжения

F = m * g * k

где

m * g = (масса на гравитацию) сила прижимающая велик к земле
k = коэффициент трения

Эта сила значительна и обычно гасит синий вектор мгновенно. Увидеть "занос на повороте" можно только если скорость уж слишком велика и/или k мал (едем по льду).

Рискну предположить что Вы никогда его не привлекали :) Поверьте, рез-т будет плачевный. Да и какую "физику" мы хотим? Все что нужно "с точки зрения физики" изложено выше. Да, в реальной жизни инерция успешно гасится. И, естественно, юзер хочет иметь такое поведение. И, конечно, его не волнуют никакие тонкости. Нажал/ввел - и вот объект имеет поведение велосипеда, машины, самолета, птицы и.т.д. А сам объект может быть просто кубик, не будет никто создавать колеса, закрылки, оперение и.т.п, это затратно и ненадежно. Ну и разумеется "какие опции дать юзеру" никакой физик Вам не скажет, это чисто работа программиста. Настоящая (а не так, темплейтики рисовать).

Ну ладно, попробуем с чего-то начать. Предлагаю дать параметр "brake" или "Inertia brake" (в тех же единицах что и ускорение) который прилагается к "синему вектору" - тому что не совпадает с текущим напр-ем силы. С клампом до нуля (т.е. тормозит но не двигает назад).

Понимаю что это предложение "наивно" - первое что приходит в голову. Критикуем, улучшаем... (в глубине души еще теплится надежда, правда совсем слабо :))  

Трение качения может быть существенно сильнее трения скольжения. Система ABS в автомобилях, как раз не позволяет автомобилю скользить.
Для велика ещё одной силой может быть сила тяжести из-за его наклона (смещения центра тяжести) в момент поворота. Что хорошо видно в соревнованиях мотогонщиков, например.


Привлекал и математиков и физиков. Результат разнонаправленный).

Все-таки требуется конкретнее сформулировать цель - чтобы было просто похоже или чтобы прям математическая модель поведения колеса, велика или чего-то ещё имитировалась?

Если нужно просто похоже, то для "физического" поведения кубика достаточно в первом приближении добавить силу, действующую на объект по нормали к целевому вектору движения, величина которой зависит от модуля угла между фактическим и целевым направлением F * sin(alpha). Поиграйте значением F, думаю, что подберете оптимальное.
За счет чего реально формируется такая сила можно не объяснять пользователю).

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

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

Ну какая же "матмодель колеса" если, как говорилось, юзер даже не собирается создавать никаких колес? Однако "просто похоже" звучит неуместно и пренебрежительно. Можно спокойно считать это "простой моделью".

Как-то мутно. Да и вызов sin не украшает (народная примета). Почему не так (псевдокод)

C++ (Qt)
float brakeInertia = ...  // величина "гашения" задаваемая юзером
vec3 force = ...  // текущий вектор силы задаваемый юзером
vec3 cur_speed = body->getLinearSpeed();  // текущая скорость объекта
 
// вектор силы инерции (синий = черный - зеленый)
vec3 interia = cur_speed - force * dot(cur_speed, force) / force.lengthSquare();
 
// применяем brakeInteria 
if (brakeInertia > inertia.length())  // полное подавление 
  interia = -interia;
else
 inertia = -interia.normalized() * brakeInteria; // частичное подавление 
 

Масса - константа, на нее домножим когда уже полезем в движок добавлять interia
Это то что Вы имели ввиду? (если нет - поправьте)

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

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

Может и так). Отсутствие четкого понимания, что чем является и в чём измеряется мешает восприятию.

C++ (Qt)
float brakeInertia = ...  // величина "гашения" задаваемая юзером
    // сила
    // мощность (работа в единицу времени)
    // процент от величины ...
    // ???
 
vec3 force = ...  // текущий вектор силы задаваемый юзером
    // здесь должен быть суммарный вектор всех сил, действующих на объект
    // с учетом сил тяжести и т.п.
 
vec3 cur_speed = body->getLinearSpeed();  // текущая скорость объекта
    // m*v^2/2 - кинематическая энергия
 
// вектор силы инерции (синий = черный - зеленый)
vec3 interia = cur_speed - force * dot(cur_speed, force) / force.lengthSquare();
    // это всё-таки составляющая вектора скорости, никак не сила
 
// применяем brakeInteria 
if (brakeInertia > inertia.length())  // полное подавление 
  interia = -interia;
else
 inertia = -interia.normalized() * brakeInteria; // частичное подавление 
    // что здесь происходит - совсем не ясно
    // здесь считается дополнительная сила?
    // что значит полное подавление?
 
// наверное, должно быть как-то так:
    // если brakeInteria дополнительная сила
    vec3 demp_force = -interia.normalized() * brakeInteria;
    // если brakeInteria процент от действующей силы (0..100)
    vec3 demp_force = -interia.normalized() * brakeInteria * force.lenght() / 100;
 
// общая сила, действующая на объект
    vec3 total_force = force + demp_force;
    // далее считаем кинематические характеристики на следующем шаге
 
    // если brakeInteria мощность, то компонента скорости перпендикулярная действию силы
    // на следующем шаге по времени, исходя из закона сохранения энергии, будет равна
    float under_root = interia.lengthSquare() - 2 / M * brakeInteria * dt
        // M - масса объекта, dt - шаг по времени
    vec3 orthogonal_velocity = under_root >= 0
        : interia.normalized() * sqrt( under_root );
        : -interia.normalized() * sqrt( -under_root );
 

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

Ваш последний ответ меня порадовал. Вот есть же люди которые хотят по-настоящему вникнуть в суть, а не так, "функции найти".

Комментировать весь код - размажется, попробую "ключевые моменты"

1)
Дальнейший расчет будет в скоростях, поэтому если, как я предлагал, "гашение" юзеру дается в тех же единицах что и ускорение (1/(sec * sec), то

C++ (Qt)
brakeInertia = user_value * dt;

Где dt - время шага симуляции. Это (максимальный) модуль скорости которую можно отнять от скорости инерции

2) Совершенно верно, это то что отнимается от скорости за время dt. Стало быть, это соответствует ускорению (в 1 / sec^2)

C++ (Qt)
vec3 a = inertia / dt;

и движку скармливается сила

C++ (Qt)
vec3 F = body->getMass() * a;

3) Это просто кламп как для трения. Гашение может затормозить до нуля (т.е. полностью), но не двигает в противоположном напр-и

3) rigidBody имеет линейную скорость и крутящий момент (члены класса). Если ничего более не происходит, то объект продолжает двигаться/вращаться с этими скоростями (по Ньютону). Силы (линейная и круговая) обнуляются перед каждым шагом и пере-создаются/накапливаются на каждом шаге. Получить суммарные силы действующие на объект  можно, но из чего они получились - хз. И "после нас" кто-то (может и сам движок) может добавить еще силу(ы).

Силы действуют по Ньютону. Если "ничего более нет" то сила тупо добавит скорость

C++ (Qt)
body->m_linearSpeed += body->m_force / body->getMass() * dt;

Однако обычно "еще много чего есть" (коллизии, constraint'ы - там страшнЭ и.т.п.), поэтому "рассчитать следующую точку пути" не имеет смысла, этим занимается движок, для этого он собсно и нужен. И юзать m*v*v тоже ни к чему - движок это сделает сам.

Ну вы "функции уже нашли" в готовом то движке, теперь форум должен бросить все свои дела, вникнуть в суть и рассказать вам как эти функции использовать... Ну а чо, дел же больше нет. :)

Ну вот, единственный собеседник - и тот юркнул в родное std::болото :'(
Ладно, добавил параметр "тормоз инерции", для поворотов работает. В аттаче траектории, для всех Acceleration=100 и MaxSpeed = 60, отличаются величиной тормоза (слева направо 3, 10, 100)

Однако 2 другие проблемы (стартового поста) это еще не решает.

"Останов объекта" - нужно как-то натравить тормоз на черный вектор (текущая скорость), но пока не соображу как (ну или "при каких условиях").

"Быстрый старт" - сама по себе проблема не великая, но маячит более общая задача: объект имеет опцию MinSpeed, т.е. не может двигаться со скоростью меньше заданной. Ну вот не ходют (нормальные) люди со скоростью 30 см/сек, а физика этого не понимает. Надо что-то придумать, но пока нет идей.

Да, ну и конечно, (в известной мере) беспокоит: а насколько "солидно" решение с "тормозом"? Где же Рунги, Куты, словом, чудесные "дифуры" которые решают все-все? Разве так можно, разложить вектор и пятью строчками (меньше) все решить? Конечно нет, это не "настоящее" решение, а так, "чтобы было похоже" и.т.п. Ну, правду сказать, я пока не вижу чем плохо простое решение (да и сообщать о его простоте юзеру необязательно). Тем более что мотив "ничего не делать т.к. это слишком сложно"  очевиден. Ну может я неправ, покритикуйте, расскажите что дает "истинное" решение (не надеюсь)