Назвать может их кто-нибудь?

Selitro
нуу.... встречный вопрос - а какая есть реальная альтернатива скелетной анимации? Если не скелетная анимация, то что?

Обычная анимация - просто движение точек относительно системы координат модели.

Цитата

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

взято отсюда

Писал, извените, какой-то глупый человек...

Цитата

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

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

Цитата

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

Это вообще не аргумент против других анимаций. Инверсная кинематика относится только к скелетной анимации.

Цитата

Иногда предоставляется возможность применять одну и туже анимацию для похожих моделей с одинаковой структурой.

Тоже не аргумент. Раз ты можешь двигать одни и теже точки у одной модели по средствам скелетной анимации, то, следовательно по логике вещей, ты можешь двигать теже точки и без скелетной анимации.

Ну и что получается? В том-то и дело, что - ничего. Ответа на вопрос "Почему лучше скелетная анимация?" так и не поступило. Никто не может дать внятного ответа?

Selitro
зайди на www.gamedev.ru и задай вопрос на том форуме... только мой тебе совет не говори никому, что Сергей Ваткин глупый человек... или можешь сказать, посмотрим что из этого выйдет

вдогонку:

Цитата

Advantages of skeletal animation are the smooth transitions while changing from one animation to the other. Additionally any number of animations can be added whereas the mesh remains constant and the same animation-cycles could be applied to different meshes while conserving a relative small memory footprint.

Это сообщение отредактировал(а) Alastis - 22.6.2005, 08:52

Цитата(Alastis @ 22.6.2005, 08:44)

только мой тебе совет не говори никому, что Сергей Ваткин глупый человек...

Да мне хоть сам Джон Кармак это написал. Глупость ведь. Вы со мной не согласны?

[quote]
Да мне хоть сам Джон Кармак это написал. Глупость ведь. Вы со мной не согласны?
[quote]

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

Плюсы скелетной анимации я бы объяснил так. Скелетная анимация позволяет собрать скелет, установить в его сочленениях (joint'ах) иерархические ограничения (contraints). С системой ограничений работает IK solver (inverse kinematics solver). Т.е. он по входному воздействию (заданному перемещению какой-то кости скелета) отрабатывает обратное распространение возмущения, в результате (это конечно зависит от правильности настроек скелета), персонаж двигается реальнее.

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

Третье. К сочленениям можно присоединять другие предметы, тогда они тоже будут подчиняться ограничениям.

Четвертое. Опять же, иерархия и система ограничений могут подчиняться внешним воздействиям (гравитация, приложения импульсов) - за примерами далеко ходить не надо, тот же ragdoll например.

Минусы: IK solver - сложная сущность. Чтобы разработать хороший IK Solver опытному программисту потребуется около трех месяцев. Субъективно, но подтверждено опытом. Из сложности вытекает требовательность к ресурсам. Но, к примеру, на большинстве машин (у меня IP3-866) можно иметь в среднем 30 (при достаточно хорошем IK solver'e) скелетно анимированных персонажей в кадре и держать FPS на приемлемом уровне. Этого вполне хватит для основных героев. А монстры пусть бегают в keyframe.

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

Цитата

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

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

Цитата

Это вообще не аргумент против других анимаций. Инверсная кинематика относится только к скелетной анимации.

В этом и есть плюс - возможность использовать инверсную кинематику.

Цитата

Тоже не аргумент. Раз ты можешь двигать одни и теже точки у одной модели по средствам скелетной анимации, то, следовательно по логике вещей, ты можешь двигать теже точки и без скелетной анимации.

Попробуй. ;)

Цитата

Да мне хоть сам Джон Кармак это написал.

Полагаешь недостаточный уровень?

Цитата(Selitro @ 21.6.2005, 05:16)

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

При оптимизации достигаеться компромисс: память<->такты CPU.

Цитата(Selitro @ 21.6.2005, 05:16)

Тоже не аргумент. Раз ты можешь двигать одни и теже точки у одной модели по средствам скелетной анимации, то, следовательно по логике вещей, ты можешь двигать теже точки и без скелетной анимации.

Эммм... А как насчёт каркаса+текстуры? Точки то каждый двигать умеет
+текстуры? Точки то каждый двигать умеет

Цитата(Selitro @ 21.6.2005, 06:21)

Обычная анимация - просто движение точек относительно системы координат модели.

Если ты имеешь в виду перересовывать все функцией SetPixel то очень медленно будет перересовываться и анимация будет подтормаживаться!

еще тут

Цитата(DrPadawan @ 22.6.2005, 16:45)

С Джоном Кармаком лучше не спорить. Тем более когда опыта нет.

Как же люди любят судить по кол-ву постов!

Цитата(DrPadawan @ 22.6.2005, 16:45)

Плюсы скелетной анимации я бы объяснил так. Скелетная анимация позволяет собрать скелет, установить в его сочленениях (joint'ах) иерархические ограничения (contraints). С системой ограничений работает IK solver (inverse kinematics solver). Т.е. он по входному воздействию (заданному перемещению какой-то кости скелета) отрабатывает обратное распространение возмущения, в результате (это конечно зависит от правильности настроек скелета), персонаж двигается реальнее.

Как же вам не понятно. Это не аргумент. Вы просто описывает возможности скелетной анимации. Суть какова? Сдвинуть точки модели. Так? Если делать через скелетную анимацию, то вам приходиться всё самим просчитывать, а если по кейфреймам, что и самый дубовый способ, то идёт тот же сдвиг точек, только без "ненужных" расчётов.

Цитата(DrPadawan @ 22.6.2005, 16:45)

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

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

Цитата(DrPadawan @ 22.6.2005, 16:45)

Третье. К сочленениям можно присоединять другие предметы, тогда они тоже будут подчиняться ограничениям.

Первый реальный аргумент.

Цитата(DrPadawan @ 22.6.2005, 16:45)

Четвертое. Опять же, иерархия и система ограничений могут подчиняться внешним воздействиям (гравитация, приложения импульсов) - за примерами далеко ходить не надо, тот же ragdoll например.

Было у меня рандеву с внутренностями альфы дума3, да хотя и в полной версии тоже самое, и вот: система ragdoll "включается" только после смерти "противника", плюс к этому идёт связка через IK. Отсюяда вывод - в данном случае, при смерти противника, и надо включать скелет, а не раньше.

Цитата(x0ras @ 22.6.2005, 17:04)

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

Ладно, будем считать, что я не умею оптимизировать код. Но соласитесь будет быстрее 500 раз обратиться к области памяти, чем 400 раз посчитать тот же cos угла.

Цитата(x0ras @ 22.6.2005, 17:04)

Попробуй. ;)

А ведь двигаю

Цитата(x0ras @ 22.6.2005, 17:04)

Полагаешь недостаточный уровень?

Если человек такое пишет - значит недостаточный.

Цитата(chipset @ 22.6.2005, 17:59)

Эммм... А как насчёт каркаса+текстуры?

Происходит движение вершин модели. В данном случае разницы нет - скелетная или кейфрефмовская.

Цитата(AISIN @ 22.6.2005, 20:05)

Если ты имеешь в виду перересовывать все функцией SetPixel то очень медленно будет перересовываться и анимация будет подтормаживаться!

Нет, конечно. Просто сдвиг опред. точек в опред. момент времени.

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

так вот какие perfomance нам предоставляет скелетная анимация по сравнению с вершинной.

1. память.
в вершинной анимации нам необходимо выделять память для геометрических данных на каждого персонажа. но мало того, еще приходиться каждый кадр гнать эти данные по AGP в видеокарточку для их дальнейшей отрисовки. то есть предположим у нас 50 персонажей в кадре. на каждого уходит по полмегабайта памяти. это 25 мегабайт данных за кадр или
порядка 100-200 мегабайт в секунду надо пересылать в видеокарточку. что очень очень много. я не говорю сколько надо системной памяти выделять для всех этих моделей. и их анимаций.

в скелетной анимации у нас есть только одна модель, которую можно один раз положить в видеопамять и забыть. CPU просто будет гнать туда матрицы скелета(полтора килобайта за кадр) и модель проскинеться в вершинном шейдере.

2. геометрический процессинг.
в вершиную анимацию надо блендить на CPU, у которого и так дел полно и который не так хорошо заточенн под такие операции, SSE конечно рулит. но это полумера. при скелетной анимации скининг может происходить в вершиных конвеерах GPU, которые в принципе простаивают зачастую. да и для GPU такое сделать намного проще и эффективнее

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

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

5. возомжность привезать к костям эфекты. например эмитеры партиклов или какое-нибудь свещение. в вершиной анимации этого делать нельзя.

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

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

8. но зато вершиной анимацей хорошо делать cloth simulation. скелеткой его тоже можно сделать, но выглядить будет не так красиво.


>Ладно, будем считать, что я не умею оптимизировать код. Но соласитесь будет быстрее 500 раз обратиться к области >памяти, чем 400 раз посчитать тот же cos угла.
совсем совсем не соглашусь. вы отстали от жизни

Цитата(Selitro @ 23.6.2005, 17:33)

Как же вам не понятно. Это не аргумент. Вы просто описывает возможности скелетной анимации. Суть какова? Сдвинуть точки модели. Так? Если делать через скелетную анимацию, то вам приходиться всё самим просчитывать, а если по кейфреймам, что и самый дубовый способ, то идёт тот же сдвиг точек, только без "ненужных" расчётов.

Как тебе не понятно? В скелетной анимации есть йерархия, а в кийфреймовой ее нет. Ето позволяет делать красивъй блендинг анимаций, что не сделаеш в кийфреймовом представлении.
IK, физика и расчленение костей очень понятнъе плюсъ.
У кейфреймовой анимации есть очень узкое и специализированное применение - не более. Всякие low-poly кучи обьектов, или очень сложная анимация, типа одеждъ.

Цитата(Selitro @ 23.6.2005, 17:33)

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

Нет йерархии. Без нее - неправильно и некрасиво, если обе анимации очень разнъе будет отстой.

Цитата(Selitro @ 23.6.2005, 17:33)

Отсюяда вывод - в данном случае, при смерти противника, и надо включать скелет, а не раньше.

В Думе может и так. В другом проекте можно и иначе...

Цитата(Selitro @ 23.6.2005, 17:33)

Ладно, будем считать, что я не умею оптимизировать код. Но соласитесь будет быстрее 500 раз обратиться к области памяти, чем 400 раз посчитать тот же cos угла.

Не факт. Даже если для cos ето так, то ето не так для линейной интерполяции. И вообще, спорить о абстрактном - не есть лучшее занятие. Только отмечу, что тактов у современнъх процах на порядок больше, чем чтений из памяти.

Цитата

Но соласитесь будет быстрее 500 раз обратиться к области >памяти, чем 400 раз посчитать тот же cos угла.

А кто говорит, что он считается 400 раз? Он считается один раз, заносится в таблицу и 399 берется обращением к области памяти...

CyberZX(gamedev.ru) - человек, который меня убедил.
Только вот два вопроса:

Цитата

5. возомжность привезать к костям эфекты. например эмитеры партиклов или какое-нибудь свещение. в вершиной анимации этого делать нельзя.

Почему же нельзя?

Цитата

совсем совсем не соглашусь. вы отстали от жизни

Вы предлогаете хранить 360 значений?
Расскажите...

sin можно по другому вычислить : на ГПУ если не ошибаюсь ...
и он это делает екстремально быстро (поговаривают за пару тактов ГПУ)

Цитата(CyberZX @ 23.6.2005, 18:58)

1. память. в вершинной анимации нам необходимо выделять память для геометрических данных на каждого персонажа. но мало того, еще приходиться каждый кадр гнать эти данные по AGP в видеокарточку для их дальнейшей отрисовки. то есть предположим у нас 50 персонажей в кадре. на каждого уходит по полмегабайта памяти. это 25 мегабайт данных за кадр или порядка 100-200 мегабайт в секунду надо пересылать в видеокарточку. что очень очень много. я не говорю сколько надо системной памяти выделять для всех этих моделей. и их анимаций. в скелетной анимации у нас есть только одна модель, которую можно один раз положить в видеопамять и забыть. CPU просто будет гнать туда матрицы скелета(полтора килобайта за кадр) и модель проскинеться в вершинном шейдере.

А ты не знаешь, GLScense делает именно так для моделей?

> Писал, извените, какой-то глупый человек...
Сам дурак.

>Цитата 
> Во-первых, это относительно малое количество данных, требуемое для хранения анимации, например, если сравнивать с морфингом. 

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

Читать с диска меньше данных, это уже не ускорение и не оптимизация?

> Цитата 
> Во-вторых, поскольку скелет представляет собой некую иерархию костей, то имеется возможность использовать инверсную кинематику.  

> Это вообще не аргумент против других анимаций. Инверсная кинематика относится только к скелетной анимации.

Других это каких? На момент написание статьи времена были перехода от морфинга к скелетке. Инверсная кинематика с морфингом? Это как? :)

> Цитата 
> Иногда предоставляется возможность применять одну и туже анимацию для похожих моделей с одинаковой структурой.  

> Тоже не аргумент. Раз ты можешь двигать одни и теже точки у одной модели по средствам скелетной анимации, то, следовательно по логике вещей, ты можешь двигать теже точки и без скелетной анимации.

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

> Ну и что получается?
Я там вначале написал :)