Russian Qt Forum

Добрый день

Дано:

- Есть базовый 3D объект, строго говоря, набор/иерархия объектов. Примеры: птица - имеет тело, крылья, лапы. Насекомое - тело, 6 ног и усики и.т.п. - все что угодно созданное юзером.  

- Создается серия таких объектов, юзер назначает число копий. С помощью движка физики и задаваемых юзером "сил" эти копии как-то анимируются. Пример: на полянке посадили напр 100 птичек. Далее юзер включил силу "вверх" - ну вот птички полетели, траектория каждой известна.

Требуется:

- синхронизировать поведение деталей (крылья, ноги и.т.п.) к имеющейся траектории объекта. Движок ни о каких деталях не знает, для него весь объект представляется упрощенным примитивом, напр box'ом. Продолжая пример с птичками выше: пока они сидят, крылья сложены, а на взлете расправляют крылья и машут - иначе как они взлетят? Разумеется все данные об анимации деталей у юзера имеются, напр записано 20 (или сколько надо) положений каждого крыла, это соответствует одному взмаху.

Соображения:

- Пример: бежит таракан. Больше скорость - быстрее подставлять ему положения ног (из имеющегося набора). и наоборот. То есть просто-напросто крутить анимацию ног с текущей скоростью. Однако этот случай не общий. У той же птички все куда сложнее. На взлете она машет активно (хотя скорость-то еще мала). В полете она может "планировать" (какое-то время взмахи отсутствуют). А если зависает в воздухе (как в фильме "Любовь и голуби") то машет изо всех сил, да и положение меняет. Др словами "простой зависимостью от текущей скорости" явно не отделаться. Повторюсь, все нужные "куски" (махание, планирование, зависание) у юзера должны быть. Нужно придумать систему которая бы позволяла юзеру их удачно и гибко "склеивать", возможно со случайными вариациями. Ну вот заготовил он какой-то "кусок", как (или куда) ему его воткнуть? Или уж совсем по-простому: что должно быть в UI?

Ну так что, будем "разрабатывать архитектуру" и все такое?  :)

Спасибо

 

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

Что-то вроде флеша, например - http://inf.1september.ru/view_article.php?ID=200801704

Это все давно есть, но это "ручная" анимация - а разговор об автоматической. Птичек (или чего еще) слишком много, париться с каждой нереально.

Ну вот, как всегда :) А совсем недавно как уверенно рассуждали: "Editor", "Toolbar", какой класс там чего должен знать о каком (впрочем я тоже участвовал). Ну да, то вещи знакомые, а здесь.... "откуда я могу это знать?". Ну так и я не знаю, надо придумать, списать-то негде (а хотелось бы)

Ну а что собственно здесь такого военного, непостижимого? Хорошо видна сущность "анимация" (записанные данные). Думается она должна знать как вписываться в текущую скорость. Или скалить ее саму или крутить loop - а возможно и то и другое. По аналогии с виджетом size: min, max, preferred, только здесь size - время.

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

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

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

Скрипты не катят, ведь закон, по которому происходит переключение, заранее не известен, так?
А если известен, то каждая птичка должна сама знать, в каком состоянии она находится, и соответственно какую анимацию использовать. Т.е. сама птичка - это контроллер анимации.

Но чтобы отличить "планирование" от "полета", скорости и высоты не достаточно. Скажем, птичка летит вниз, но машет крыльями - это по какому закону должно быть тогда? :)

Как контролировать десятки объектов с разной анимацией и разным временем запуска?
Сделать контроллер.

 

По классике
Так вот, таких гордых птичек мы не планируем. Многого от нее не требуется - просто пусть себе машет крылышками как-то интересно - чтобы не выглядело все однообразно/механистично. Никакой она сам себе не контроллер.

Момент переключения - да, тут сложности. Как-то его надо задавать "извне", причем действиями пользователя. Пока неясно как. Но никакого real-time нету - сначала пусть движок обсчитает все траектории, а потом уж займемся анимацией деталей.

а как тогда совмещаются эти требования?


и

Ручная/базовая анимация - это нулевой уровень, с которого все начинается. Для каждого объекта на линейке времени юзер создает ключ(и). Напр на кадре 50 лапка должна занять такое-то положение, а на кадре 100 - уже другое. Рез-том проигрывания кадров 50-100 будет какое-то движение объекта или его части.

Автоматическая анимация задумывается комбинация заготовленных ручных, обычно для многих объектов. Напр текущий (глобальный) кадр уже 200, но зная закон изменения (напр базовая анимация просто зациклена) мы вычисляем что текущее положение лапки как на кадре 50, оттуда его и берем. Для др объекта целевой кадр возможно будет другим в зависимости от параметров "кручения" базовой.

Речь о том что нужен некий "контроллер" переключения базовых анимаций. Напр на кадрах 0-50 птички сидят и/или чего-то клюют (для каждой крутится одна базовая анимация). Теперь они полетели, возможно все вместе или как-то по частям, как движок сделал. Траектория полета каждой известна. Вот надо обеспечить переход с одной заготовленной базовой анимации "сидим" на другую "летим".

С точки зрения ООП переключением анимаций должен заниматься объект птички, поскольку только птичка знает о своем текущем состоянии. Каждая птичка должна являться контроллером. Если это не получается сделать сейчас - необходимо пересмотреть архитектуру проекта.

Объект птички - это всего лишь записанная траектория движения, по сути сырые исходные данные, с какой стати он должен что-то решать?

Так пересматривайте - все что есть сейчас изложено в стартовом посте  :)

Ой :) А может не надо?

Контроллер нужен в том или ином виде. Или на каждую, или общий для птичек.
Но для начала нужно ответить на вопросы
1) так всё же автоматически, или же задаётся пользователем?
2) если задаётся, то в каком формате и что (трактория, анимация привязана к положению или же к направлению).

И лишь после ответа на эти вопросы, можно уже дальше рассматривать данный конкретный случай.

Контроллер, прежде всего, должен следить за состоянием объектов и за его изменением. Т.е. должен определять момент, когда сидящая птичка вдруг начинает лететь, например. Т.е. на каждом шаге симуляции каждая птичка должна быть проверена на предмет изменения скорости-высоты-положения-ктознаетещечего. Состояние поменялось - запомнили его - воткнули новую анимацию. Только вот где тогда хранить все эти состояния прикажете? Логичнее все-же хранить их в "птичках", а не в "глобальном конроллере", иначе получится каша из структур и массивов.

Что хочет юзер (пример).

- посадить на поляну N птичек (напр 100), пусть напр они спокойно едят 

- в заданный момент (напр юзер решил на кадре 50) птички полетели, здесь много вариантов в зависимости от параметров полета

- сделав кружок-другой они приземлились и опять едят

Вот все. Разумеется юзер понимает что все нужные данные он должен иметь - и параметры и траекторию полета стаи задать, и все едят/летят/приземляются должны быть заготовлены в виде набора всех нужных кадров - конечно для 1 птички, для 100 это сделать руками уже нереально.

Но вот "формат", "контроллер", то-се - совершенно не его дело, это все решает программист. Нужны от юзера какие-то еще данные - пожалуйста, задумывайте, предлагайте. А юзер будет вводить - ну конечно данные должны быть разумны.

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

Ну так раз у вас есть данные все, тогда в чём проблема? Рассчитывайте на каждый кадр у птичек состояние по этим данным и отрисовывайте.

Тут проблема в чём? В том, как задать все эти параметры и данные, чтобы пользователю было удобно, а не 100 кликов в позицию лететь.

PS вообще не вижу тогда проблемы, если опускаем данные задаваемые пользователем. Данные есть, положение в пространстве есть, их траектории есть (пусть даже пользователь и загребётся их описывать), рассчитываем кадр. В чём проблема то тогда?

PPS алгоритм для рассчета птичек нужен, чтобы пользователь не вводил данные. А если он всё ввёл, тогда и алгоритм не нужен.

:) Прочитайте стартовый пост. Там в параграфе "соображения" 2 примера - простой и посложнее.

В данный момент вопросов в вашей теме целых несколько.

1) синхронизация деталей анимации к траектории. (и тут же этот вопрос отсеивается словами "а ведь они разные могут быть, пусть решает пользователь")
2) как сделать автоматическую работу анимации. (без юзера)
3) как сделать ручную работу анимации. (с юзером)
4) в каком формате сделать удобное переключение анимаций пользователем. (видимо аспект "каким образом", "каким инструментом")
5) обработка дополнительных событий при автоматической и ручной работе анимации при переключении анимаций пользователем. (или можно соотнести к предыдущему вопросу)
6) необходимость создания контроллера переключения базовых анимаций ( можно соотнести предыдущими вопросами)

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

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

Не борзейте, а то быстро на неприятности нарветесь :)

Т.е. вы хотите один ответ, одинаково правильно отвечающий на все эти вопросы? Мда...

Если вопрос в том - какие средства управления анимацией давать пользователю, то мировая компьютерная наука на это давно ответила. Есть анимация таймлайновая, с заданием траекторий, а есть процедурная (там где птички летают как бы сами по себе, но не сталкиваются). В настоящее время активно используются обе, поскольку одна позволяет проще решать одни задачи, другая другие. Наиболее яркий представитель таймлайновой анимации - 3ds MAX. В нём таймлайн первичен, но есть поддержка событий. Наиболее мощный и яркий представитель процедурной анимации - SideFX Houdini. Там события первичны, но есть возможность использовать таймлайн. В Maya 3D активно используются и процедуры, и таймлайн.

Если надо посмотреть на то, как лучше всего сделать управление событиями, и вообще как управлять процедурной анимацией, то надо установить учебную версию Houdini и посмотреть. Не знаю точно как сейчас, но некоторое время назад учебная версия Houdini была доступна бесплатно. От взрослой она отличалась некоторыми ограничениями при рендеринге, хотя средства редактирования все как у взрослой.

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

1) Создать новый нод в Node editor
2) Внутри этого нода написать скрипт (требуется знание не только скриптов но и API)
3) Повторить эту процедуру еще дважды (там по теории 3 параметра рулят)

Это примерно половина тьюториала (метров 500 в mp4). На большее меня не хватило. Просмотрев остаток "по диагонали" я так и не увидел где же задается "махание крылышками" (то что я искал)

Я бы не выделял каких-то "ярких". Интерполяция/сплайны везде одинаковы. Кстати далеко не всегда они есть - часто тупо "данные для каждого кадра".

Есть удобный термин CG

Если ответила то поясните, хотя бы в общих чертах, как должна выглядеть "процедурная" анимация. Потому что у меня впечатление наоборот - каждый пакет городит свой огород

Не... по тьюториалам на Houdini смотреть - это всё равно что изучать Windows по хэлпам. Бесполезное занятие. Я в своё время похерил тьюториалы, поставил пакет, и изучал его по документации и напрямую. Кстати, у него есть (была...) бесплатно доступная полная документация в виде толстого PDF документа. В нём всё описано. AFAIR он установится вместе с пакетом.

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

Процедурная анимация - это не конкретный интерфейс приложения, это принцип управления объектами, более близкий к реальному миру, чем таймлайн. Как и "CG", это давно устоявшийся термин. Use Google. Houdini выделяется тем, что в нём все возникающие вопросы решены и хорошо проработаны за два десятилетия его существования.

В Maya 3D тоже реализована процедурная анимация, и даже идеология очень похожая - но интерфейс совершенно другой.

Управление у меня есть - траекторию движения каждой птички я считаю. Теперь задача в том чтобы заставить их разумно/интересно махать крылышками. Подробнее неск раз писал выше

Крылья - это отдельные объекты, но связанные с другими объектами в иерархический объект "птичка". Каждому объекту в иерархии соответствует процедура анимации его каким-либо способом, с возможностью обработки событий. Чтобы представить себе, что такое "процедура анимации", и как её имеет смысл сделать, лучший способ - установить и разобраться с Houdini. Или хотя бы прочитать его мануал. В принципе, можно Maya 3D, но он менее наглядный и интуитивно понятный, чем Houdini.

Ну а почему Вы думаете что я ничего не смотрел, доки не читал?  :) Ладно, я Вас понял примерно так
Верно?

Нет. Как это сделать - я знаю. Хотя бы потому, что я пользовался Houdini и делал на нём анимации. Правда довольно давно, но он уже тогда был очень мощным инструментом.