Ответ: Sigel
 

1. Загрузка заскиненной модели из файла
2. Чтобы вершины двигались вслед за комтями (хотя бы без коэффициентов: 1 вершина - 1 кость)
3. Возможность двигать, поворачивать кости
4. Анимация по ключ кадрам.

Ответ: Sigel
 

5. загрузка анимации отдельно от геометрии?

Ответ: Sigel
 

труъ

+ 6. возможность запускать анимацию отдельных костей (массив названий либо массив номеров)

Ноето всё я думаю будет несложно если есть основа. Вот она - самое главное.

Ответ: Sigel
 

тест спрайтов.
в сижеле - каждый такой спрайт - это отдельный объект. поетому они довольно тормозные. В частном случае нужно использовать или спрайтовые системы, или системы чаастиц.

Но тем ни менее, у меня они работают быстрее чем в блице. Вот пример:
http://forum.likosoft.ru/attachment....0&d=1232901068

если в счстеме частиц на 50к частиц демка работает на 130фпс
то на таком же количестве спрайтов производительность падает до 50фпс

Re: Sigel
 

180 фпс если всё на макс. ... кстати багу заметил - если быстро вертется вправо-влево то появляется рябь, тоест картинка ак-будто не успевает обновлятся в на неё уже следующий кадр лезет...

Ответ: Sigel
 

пилец..нубские баги... а как по твоему у тебя 180 если всинк не включон?

Ответ: Sigel
 

Олег, начсёт анимации, я интерфейс удобным представляю такой:
Загрузка модели может быть простой или с костями, а анимация всегда хранится в отдельных файлах, при этом применяется по имени кости. Но потребность в этом, вызвана тем чтобы реализовать возможность подргузки анимации под немного разные скелеты, а применение матриц будет влиять на скелет, и кости по именам, тем самым это даст хорошую возможность иметь много персонажей, иногда с доп костями а иногда без них: просто анимация будет находить какие есть кости в скелете и преминять на них матрицы, если нет такой кости в скелете, то просто игнорирует её и всех её детей.
Возможность разбивать анимации на секьюэнсы. К примеру у нас есть модель и подгружена анимация из одного файла, получается есть только нулевой секьюэнс (который будет всегда содержать всю анимацию), далее делаем извлечение секьюэнса, появится первый (простой индекс). Также и склеивать в один, типо: MergeSequences(Model,Seq1,Seq2), таким образом в Seq1 будет содержать и собственную и потом дополненую.
Второй важный моммент, это возможность кастомно указывать костям какую анимацию играть: таким образом реализуется морфинг, если это технически не затруднительно. Обязательно наличие флага, обозначающего что применение анимации кости, будет также влиять на все наследственные кости.
Энтити класс Bone - если это также не затруднительно, даст возможность применять манипуляции его матрице, кручения, перемещения, скейл.
Получение локальной координаты относительно отца кости, всей модели или мира. Этот моммент думаю тоже немало важен.
Ну и естественно работа с так сказать таймлайном секьюэнса, направление анимации, принудительная установка текущего кадра, и параметр скорости, который даст возможность делать паузу или синхронизировать анимацию. Желательно эти функции по отдельности, относительно скорости темболее.
Ну и конечно множество Get функций, для получения информации.
Что думаете насчёт такого интерфейса, и какие он имеет минусы/плюсы, и что можно поменять и улучшить с точки зрения юзабетельности?

Ответ: Sigel
 

Это я, к сожалению, могу исправить только одним способом - включением всинка, но тогда и фпс будет не больше 60-ти.

MoKa, спасибо! Очень понравилась идея с игнорированием костей (если их нет). На секвенсы анимацию лучше всего бить в редакторе, и давать секвенции имя - например "run","idle","attack1". И вытаскивать секвенцию чтобы можно было не только по кадрам, но и по имени.
Управления костями скорее всего будет чуть сложнее чем в блице. По крайней мере запихивать в общий список и наделять кость всеми возможностями простого entity я не буду. Скорее всего можно будет только управлять ее позицией, поворотом, может быть скейлом, полчуать все это как в мировых координатах, так и в координатах объекта, может быть еще в EyeSpace, для передачи в шейдер. И скорее всего ето будет выглядеть так:
Bone* Skeleton->GetBone(Entity* EntityInstance,int boneindex);
примерно такую идеологию я опробывал на системе частиц, она хоть и муторная, но довольно производительная (хранить кости в списке entity, а не в неком, общем списке).
возможно понадобится и перегруженная версия со строкой - для получения кости по имени.

Спасибо за дельное предложение!

тест бампа:
Q - отключить всинк
SPACE - моушнблюриить картинку

Ответ: Sigel
 

Насчёт того что у костей будут свои функции, это добавит читабельности, и посути я согласен, просто имел ввиду что примерно значение функций манипуляции, были аналогичны энтитявским.
Насчёт секьюэнсов, дык загружаешь простую модель и анимацию у которой в редакторе небыли указаны секьюэнсы, он просто пихнёт в нулевой секьюэнс всю анимацию. А если были секьюэнсы указаны в файле, тогда он загрузит всю анимацию в нулевой секьюэнс, а также добавит и дальше секьюэнсы, которые естественно нужно будет сперва найти по имени, типо: FindSequence(Entity%,Name$), тоесть он просто также разобьёт что и если кодом в первом варианте.

Ответ: Sigel
 

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

Может покурить исходники блитца ?

Ответ: Sigel
 

tormoz, а чем моя концепция интерфейса уступает блицевой? Помоему не сильно и отличается и т.п. но по мне так более интуитивна и даёт больший функционал. Как считаешь? Можно, даже нужно обсудить это более конкретно, т.к. это немало важно, но по мне так отталкиваться от блица, уже глупо..

Ответ: Sigel
 

ты просто привык к ней))

да, я тоже так считаю.

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

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

Ответ: Sigel
 

Удобство анимации блица заканчивается там, где возникает необходимость анимировать разные кости отдельно.
А если с этой фичей - так большего мне и не нужно. ИМХО.

Ответ: Sigel
 

Назови реальный пример, когда возникает такая необходимость?

Ответ: Sigel
 

Да скоко угодно!

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

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

Олег, неужели сам не сталкивался? Не верю!