Comments 9
Совет №0: прогоните текст через word или любой другую доступную систему проверки орфографии. Он будет вызывать меньше раздражения — и как следствие, больше желания помочь.
Спасибо за статью, довольно интересный подход. Привязка скелетной анимации к физике всегда довольно непростая задача, и всегда очень специфичная. Обычно включает себя упрощения якобианов и магию. Игры это иллюзия, так что магии много :)
Можно для начала реализовать ragdoll для своей скелетной модели. По этому топику можно найти множество информации, попроще что бы, советую доклад о Diablo 3 Ragdolls с GDC2012.
Сама Ваша модель довольно наивна, но, будет работать. Современные анимации стараются считать больше (если не полностью) на GPU, например.
Что бы посмотреть другие примеры, есть множество источников. Для простоты — есть Spine, редактор 2д скелетных анимаций. Он с открытым форматом и множеством реализаций клиентской стороны с открытым кодом. Оттуда можно почерпнуть знания. Если хочется чего-то серьезного, всегда есть серезные проекты, например Unreal 4, за 20$ можно получить полный исходный код.
Можно для начала реализовать ragdoll для своей скелетной модели. По этому топику можно найти множество информации, попроще что бы, советую доклад о Diablo 3 Ragdolls с GDC2012.
Сама Ваша модель довольно наивна, но, будет работать. Современные анимации стараются считать больше (если не полностью) на GPU, например.
Что бы посмотреть другие примеры, есть множество источников. Для простоты — есть Spine, редактор 2д скелетных анимаций. Он с открытым форматом и множеством реализаций клиентской стороны с открытым кодом. Оттуда можно почерпнуть знания. Если хочется чего-то серьезного, всегда есть серезные проекты, например Unreal 4, за 20$ можно получить полный исходный код.
Прикольно, это 2D скелетка? Давно хотел попробовать наряду с имитацией освещения в 2D. Только вот в статье нет ни строчки на C++ :-)
Брр. Как насчет кватернионов?
Слишком сложно.
На мой взгляд было бы логичнее сделать следующее:
1) Перевести все трансформации на квартернионы (либо с позицией, либо двойные), как писал ZimM. В случае с 2D вся их математика значительно упрощается (для ориентации достаточно zw координат).
2) Joint должен хранить:
— индекс родительской кости, и -1 в случае если это root
— имя или хеш имени, для реиндексации (если анимация должна подходить для другого меша, всяких обвесов или оружия)
— инвертированную базовую трансформацию в которой он был прикреплён к мешу или объекту
3) Анимация должна хранить:
— информацию о скорости проигрывания (FPS), количестве кадров в анимации, количестве задействованных Joint'ов
— индекс Joint'а и все его KeyFrame (в виде кватернион+позиция, или двойных кватернионов, что в случае с 2D звучит страшнее чем на самом деле)
4) Для модели хранить стек анимаций, каждая анимация которого имеет динамически изменяемый «вес». Это позволит делать так называемый Merging & Blending анимаций друг с другом (бег + махание руками = бежим и машем)
5) Каждая вершина геометрии (меш) должна хранить индексы влияющих Joint'ов (2 вполне достаточно) и их веса. В случае если достаточно одного влияния, вес будет не нужен (всегда = 1) и можно будет избавиться от инвертированной трансформации из п. 2 применив её к самой геометрии перед сохранением (оптимизация runtime расчётов).
6) Геометрия должна хранить индексы и имена влияющих костей для реиндексации, выработка стандарта имён в скелете позволит применять одну и ту же анимацию для различных мешей, разных пропорций.
7) В итоге, пробежавшись по всем Joint'ам скелета, собрав итоговые интерполированнные трансформации для текущего кадра в стеке, получишь массив итоговых трансформаций, который необходимо умножить на соответствующие инвертированные трансформации из п. 2 (если не используется оптимизация п. 5), и передать всё это добро в шейдер. Далее всё весьма тривиально.
Может что-то забыл, но как-то так…
На мой взгляд было бы логичнее сделать следующее:
1) Перевести все трансформации на квартернионы (либо с позицией, либо двойные), как писал ZimM. В случае с 2D вся их математика значительно упрощается (для ориентации достаточно zw координат).
2) Joint должен хранить:
— индекс родительской кости, и -1 в случае если это root
— имя или хеш имени, для реиндексации (если анимация должна подходить для другого меша, всяких обвесов или оружия)
— инвертированную базовую трансформацию в которой он был прикреплён к мешу или объекту
3) Анимация должна хранить:
— информацию о скорости проигрывания (FPS), количестве кадров в анимации, количестве задействованных Joint'ов
— индекс Joint'а и все его KeyFrame (в виде кватернион+позиция, или двойных кватернионов, что в случае с 2D звучит страшнее чем на самом деле)
4) Для модели хранить стек анимаций, каждая анимация которого имеет динамически изменяемый «вес». Это позволит делать так называемый Merging & Blending анимаций друг с другом (бег + махание руками = бежим и машем)
5) Каждая вершина геометрии (меш) должна хранить индексы влияющих Joint'ов (2 вполне достаточно) и их веса. В случае если достаточно одного влияния, вес будет не нужен (всегда = 1) и можно будет избавиться от инвертированной трансформации из п. 2 применив её к самой геометрии перед сохранением (оптимизация runtime расчётов).
6) Геометрия должна хранить индексы и имена влияющих костей для реиндексации, выработка стандарта имён в скелете позволит применять одну и ту же анимацию для различных мешей, разных пропорций.
7) В итоге, пробежавшись по всем Joint'ам скелета, собрав итоговые интерполированнные трансформации для текущего кадра в стеке, получишь массив итоговых трансформаций, который необходимо умножить на соответствующие инвертированные трансформации из п. 2 (если не используется оптимизация п. 5), и передать всё это добро в шейдер. Далее всё весьма тривиально.
Может что-то забыл, но как-то так…
Sign up to leave a comment.
Скелетная анимация в первый раз