Comments 16
Имеется ли практическая реализация? Какие результаты?
Немного смущает «Алгоритм повторяется до тех пор, пока позиция конечного элемента не приблизится к цели на достаточное расстояние» — я так понял, что это пересчет всего дерева костей, и как это стало быстрее той же интерполяции?
Немного смущает «Алгоритм повторяется до тех пор, пока позиция конечного элемента не приблизится к цели на достаточное расстояние» — я так понял, что это пересчет всего дерева костей, и как это стало быстрее той же интерполяции?
Над реализацией пока-что работаю.
Для случая с деревом без ограничителей новая позиция следующих, за конечным, узлов будет равна pNext + (pCurrent — pNext).normalized * distToNext. Причём тут интерполяция? В статье ни слова о ней.
Для случая с деревом без ограничителей новая позиция следующих, за конечным, узлов будет равна pNext + (pCurrent — pNext).normalized * distToNext. Причём тут интерполяция? В статье ни слова о ней.
Классические методы ИК тоже итеративные. Но этот вариант, скорее всего, сходится быстрее, к тому же учитывает предыдущее положение, а значит и движение получается более естественным.
А не могли бы вы пояснить почему получается ограничивающий эллипс, мне почему то кажется что это должна быть дуга.
У вас (или автора оригинала) ошибка в начале псевдокода
написано d[i] = | p[i+1] -t | for i = 1,…, n-1
а должно быть d[i] = | p[i+1] — p[i] | for i = 1,…, n-1
написано d[i] = | p[i+1] -t | for i = 1,…, n-1
а должно быть d[i] = | p[i+1] — p[i] | for i = 1,…, n-1
Ну, еще один инеративный ИК метод. Правда он будет работать только с цепочками? Т.е. с конструкциями типа скелета, где скорее граф костей ничего не получится?
Когда я реализовывал очень похожий алгоритм, у меня были проблемы вблизи сингулярных положений — например, выход из полностью вытянутой позы может происходить большими рывками.
Вообще, вы пробовали оценить в чем минусы этого алгоритма? Всегда ли он сходится, будут ли рывки при проходе конечного узла по разным траекториям, например (у меня были).
Вообще, вы пробовали оценить в чем минусы этого алгоритма? Всегда ли он сходится, будут ли рывки при проходе конечного узла по разным траекториям, например (у меня были).
Я не сталкивался с такой задачей, однако если бы пришлось — я сразу бы посмотрел в сторону физики. Т.е. рассматривал бы скилет как систему материальных тел, соответственно, когда нужно что-то пододвинуть — я бы создавал силу, направленную в точку, куда двигаем и дальше бы моделировал физические связи. Это бы позволило сделать растяжение, сжатие, ограничение по углам, скорость, даже физические ограничения, например принципиальную невозможность какого-то движения из-за нехватки силы, да и движение разных частей с разным угловым ускорением прибавило бы реалистичности.
Чем представленный в статье подход лучше? Как он справится, если точку нужно приблизить, а не отдалить от фиксированной?
Чем представленный в статье подход лучше? Как он справится, если точку нужно приблизить, а не отдалить от фиксированной?
Sign up to leave a comment.
Инверсная кинематика: простой и быстрый алгоритм