Общий вопрос анимации - PullRequest
       4

Общий вопрос анимации

1 голос
/ 05 ноября 2010

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

(Просто чтобы установить сцену, хотя это не особенно относится к вопросу: я работаю с opengles на iphone)

Если я пойду к художнику и скажу им, чтобы я создал 3d-модель анимации ходячего гнома, которая не будет динамичной, как они будут давать мне данные? Будут ли они: а) Создать 3d модель костей, анимировать пути костей в списке путей вместе с метками времени и типом интерполяции, а затем просто определить 3d-модель каждой кости? Т.е. ходячим карликом будут позвоночник, руки, руки, ноги, ступни, шея, голова, а затем модельер создаст части для каждой из этих костей и даст мне путь анимации ...?

или б) Модельер создает одну полную модель, а затем деформирует ее и каким-то образом сохраняет деформацию

* 1008! Или я не прав? Какой формат объекта лучше всего подходит для 3D-анимации?

Будем весьма благодарны за любые другие советы / рекомендации по методам, механизмам и т.п.

1 Ответ

6 голосов
/ 08 ноября 2010

У вас есть в основном правильные идеи. Есть два основных подхода, скелетный и некелетный, оба из которых имеют тенденцию включать поставку ключевых кадров.

При не скелетной анимации вам может быть предоставлено, скажем, десять кадров анимации для рисования во время ходьбы и количество времени, необходимое для перехода от одного кадра к следующему. Таким образом, это точный трехмерный аналог способа, которым работали 2d пиксельные спрайты. Вы можете определить, какой кадр в данный момент виден, или применить анимацию движения. Если вы знаете, что находитесь на полпути между фреймом, в котором вершина находится в V1, и фреймом, в котором эта же вершина находится в V2, вы можете расположить его на полпути между V1 и V2. Таким образом, вы линейно интерполируете все положения вершин между кадрами. Это выглядит немного плавнее, чем просто пролистывать кадры, но, как правило, немного искажает геометрию, поэтому вам все же нужно, чтобы кадры были достаточно плотными.

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

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

С точки зрения iPhone, в ES 1.x вам, скорее всего, придется выполнять не скелетную анимацию на процессоре, что не является такой большой проблемой с производительностью, как вы можете догадаться, потому что PowerVR MBX не на самом деле все равно храните объекты буфера вершин в видеопамяти. Пока вы накапливаете свой буфер в формате, удобном для PowerVR (выравнивание имеет значение, главным образом, чередование положения / текстурных координат / нормалей / и т. Д. В предписанном порядке, также полезно), тогда отправка в OpenGL не намного дороже чем использование объекта буфера вершин.

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...