Инверсная кинематика: простой и быстрый алгоритм

[MrGobus]

Имеется ли практическая реализация? Какие результаты?
Немного смущает «Алгоритм повторяется до тех пор, пока позиция конечного элемента не приблизится к цели на достаточное расстояние» — я так понял, что это пересчет всего дерева костей, и как это стало быстрее той же интерполяции?

[6opoDuJIo]

Над реализацией пока-что работаю.
Для случая с деревом без ограничителей новая позиция следующих, за конечным, узлов будет равна pNext + (pCurrent — pNext).normalized * distToNext. Причём тут интерполяция? В статье ни слова о ней.

[tac]

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

[6opoDuJIo]

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

[SHVV]

Классические методы ИК тоже итеративные. Но этот вариант, скорее всего, сходится быстрее, к тому же учитывает предыдущее положение, а значит и движение получается более естественным.

[tzlom]

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

[6opoDuJIo]

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

[Chaos_Optima]

У вас (или автора оригинала) ошибка в начале псевдокода
написано d[i] = | p[i+1] -t | for i = 1,…, n-1
а должно быть d[i] = | p[i+1] — p[i] | for i = 1,…, n-1

[6opoDuJIo]

Да, ошибка у меня, опечатался. Спасибо.

[Shchvova]

Ну, еще один инеративный ИК метод. Правда он будет работать только с цепочками? Т.е. с конструкциями типа скелета, где скорее граф костей ничего не получится?

[Chaos_Optima]

3 Параграф статьи разве не о об этом?

[6opoDuJIo]

В случае с графом таковой разбивается на несколько цепей, а общие звенья становятся суб-базами.

[Amomum]

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

Вообще, вы пробовали оценить в чем минусы этого алгоритма? Всегда ли он сходится, будут ли рывки при проходе конечного узла по разным траекториям, например (у меня были).

[6opoDuJIo]

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

[kahi4]

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

Чем представленный в статье подход лучше? Как он справится, если точку нужно приблизить, а не отдалить от фиксированной?

[tac]

тем, что он не занимается лишним… а то, что вы предлагаете сходится, если вообще сходится, в сотни раз медленее