Russian Qt Forum

Добрый день

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

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

Как этот момент считать и какие опции должны быть ?

Спасибо

Прелесть таких задачек в том что наш (или по крайней мере мой) "богатый опыт" оказывается совершенно нулевой :) И я бы тоже заявил типа "такая задача меня недостойна !" - но сделать обязан.

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

Где поселить этот ф-ционал? Должен ли он принадлежать двигаемому объекту (чайнику), быть его свойством? Решил что нет, чайник может скользить или даже падать, при этом совсем необязательно "носиком вниз". Поэтому "face-forward" должно принадлежать объекту "сила". Вроде логично: эта сила направляет носик вперед, а другая (напр гравитация) может и нет. Однако сразу получаю проблему - а что если напр-е движения не совпадает с напр-ем силы? См аттач: сила приложена по оси X и достаточно велика чтобы преодолеть уклон. Хмм... верхний выглядит более естественно.

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

Момент перпендикулярно крышке чайника развернёт его как надо

Неужели, 3 месяца спустя - начало (плодотворной) дискуссии?  :)

1) Вероятно Вы хотели сказать что нужно вращать чайник вокруг его локальной оси Y. Но чайник - это всего лишь стандартная модель для примера, поэтому "перпендикулярно крышке" - не разговор, вопрос "какую ось вращения юзать"  остается открытым

2) А как (или насколько) его вращать, т.е. на сколько градусов он должен повернуться за шаг симуляции dt ?

3) Стандартная проблема инерции. Если мы начали вращать, то чайник приобрел угловую скорость, которая сама по себе никуда не исчезнет - т.е. он будет вращаться вечно, как от этого избавиться? Заметим что текущая ось вращения может измениться

Да, обычно задача имеет какой-то известный "контекст"  напр используемые классы, стандартные решения и.т.п. А здесь ничего этого нет, только вызов API, все остальное нужно определять самому, устанавливать какие-то правила (отвечая конечно  за их разумность). Дело не в том что я, мол, не хочу таскать "ис каропки". Очень даже хочу - но вот "каропки" никакой нету  :)

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

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

C++ (Qt)
body->applyTorque(btVector3(0, M_PI * 2, 0) * inertiaTensor);
 

Это добавит угловую скорость 1 оборот / сек. На inertiaTensor можно не обращать внимания - она считается 1 раз при создании body
Ну "какую ручку крутить" - понятно, она здесь одна. Но что конкретно делать? Какой вектор подавать в вызов applyTorque ?

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

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

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

Приступим. Если вращать - нужна ось, откуда ее взять? Можно дать юзеру параметр, но самое разумное - то что уже прозвучало ("перепердикулярно крышке"), т.е. текущая ось  Y объекта. А центр вращения просто = центру объекта.

Хорошо, допустим крутим вокруг локального Y, это строка или столбец в матрице объекта, она всегда есть. Что еще надо определить, какие еще утверждения сделать?

Пусть мышкой указывает ось. Щёлк по чайнику, через эту точку и центр чайника ось. И ещё пусть направление вперёд задаст, отметив точку на плоскости.
Кстати, что будет если чайник наткнётся на плоскость при вращении?

Направление движения (красный вектор на рисунке) задается силой, см два первых поста. Возможно Вы имели ввиду задать "а что считать носиком", ведь в общем случае это не определено. Ну неплохо напр попапка "Face Direction" (в установках объекта) с выбором +X, -X, +Z, -Z

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

Однако мы отвлеклись от темы  :)