Russian Qt Forum

Добрый день

"Анимация" - термин весьма обширный, но здесь это не мешает. Пусть это анимация размеров прямоугольника средствами Qt. Если первый кадр == последнему, это loop который может быть зациклен, т.е. повторен любое число раз.

Пусть есть набор различных анимаций (циклов и нет). Можно создавать различные цепочки/последовательности анимаций комбинируя  базовые анимации. При этом должны соблюдаться очевидные ограничения:

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

- первый кадр следующей анимации должен быть == последнему кадру предыдущей. Др словами, все плавно, без рывков

Да, да, все ясно, что надо-то?  :) А надо дать юзеру возможность (удобно) комбинировать базовые анимации. Простой пример "реакция на событие". Если текущий кадр (global_frame) = 100, то после окончания текущей должна быть выбрана анимация с именем "run" из набора. На первый взгляд, это совсем просто (по крайней мере из кода). Но.. А если "run" несовместима с текущей? Или достижима но через какую-то промежуточную? И.т.п.

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

Частенько, присматриваясь ко всяким графам, я ловил себя на мысли типа "боже, какой головняк с нодом "if". И все потому что не хочет освоить пытон". И вот представилась возможность. Хорошо, вот пытон (уже интегрирован в приложение), есть объект анимацией которого надо управлять. Есть набор/контейнер  базовых именованных анимаций и есть ф-ции событий (global_frame() в примере выше)

И..что? Как (или что) писать на пытоне ??? Как-то я совсем растерялся :) Даже без всяких событий нужно как-то задать последовательность анимаций - а как?

Ну вот решил спросить здесь (где многие любят пытон  :))

Спасибо

Чего молчим? Задача интересная, придумать можно много чего. Собсно нужно разработать Python API. С точки зрения хоста (приложения на С++) все ясно: есть объект, у него есть текущая анимация и текущий кадр этой анимации. Хост знает что с этим делать. На каждом кадре(?) вызывается пытон-скрыпт который решает какая анимация должна быть установлена как следующая.

А вот с пытон-частью хужее. Напрашивается напр так
Да, с пытоном знакомился (не более того) неск лет назад, и синтаксис совсем не помню. Ну ладно, дойдет до дела - почитаю. Приведенный псевдокод наверно будет работать, но как-то уж очень тупо, только для 2 анимаций. А если их хотя бы 3, напр idle, walk, run, и соскочить на run можно из walk (но не из idle) ?

Это противоречит идее/гибкости скриптов. Мы не можем (и не должны) знать "что конкретно понадобится", нужно создать общее API с помощью которого можно достичь желаемого. Иначе смысла в скриптах нет, если все-все определено, то проще на плюсах.

Ну и конечно
Да с огромным удовольствием, но где ж его взять-то? И есть ли оно в природе? Ну есть напр QStateMachine, конечно прочитал. Вроде вещь неплохая но логику поведения она за меня делать не будет

ну, вот я прочитал раза 3, нифига (почти) не понял:

- о каких анимациях вообще идёт речь?
- что значит "несовместимые анимации"?
- юзер должен их через гуй собирать или как?
- при чём тут пытон?
- при чём тут события?

и т.д...

Ну блин, включили непонималку :) Хорошо, вот более образный пример. Есть человек, для него записана анимация idle (стоит, дысыт, лупает глазками) и анимация walk (идет, записаны шаг левой и шаг правой). Если первый кадр (данные) walk совпадает с последним idle  - то walk может начаться после idle, иначе нет. Юзер натырил таких базовых анимций с веба, теперь их надо как-то склеивать/повторять. Простой пример - до кадра 100 человек стоит (зациклена idle), потом пошел (зациклена walk).  Но это один вариант/сценарий, а может быть сколько угодно (как захочет юзер) и заранее они не известны. Поэтому решить "опциями" не удается. Отсюда скрипты, пытон и.т.п   

Апну темку, уж очень хороша. Вот еще типовая сцена

100 и более char'ов сидят на стадионе и смотрят матч. Ну для каждого крутится какая-то idle анимация (напр говорит с соседом, поворачивает голову). Число таких анимаций невелико, может всего 3-4. Но они крутятся со сдвигом, однообразие не так уж очевидно. И тут, на каком-то кадре, хирак - ГОЛ! Сhar'ы встают, машут руками (включается анимация "аплодисменты"), потом опять садятся.

Все char'ы и все анимации имеются, нужно только включать нужные в нужный момент. Прикинем еще неск ситуаций. Напр юзер может захотеть чтобы char'ы вскакивали не все сразу, а сначала передние ряды и.т.д. Или аплодируют не все, болельщики др команды наоборот. Очевидно делать это "явно", на плюсах, бесполезно, нужны скрипты. Тогда какое API, что энтузиаст должен писать ?

Но такие задачи нас почему-то не привлекают. Вот кушать QML ложками - то да :) А так
:'(
  

А зачем пайтон в форуме за кьют? Шоп, типа, "по модному"? :)

Вверху по меньшей мере дважды сказано почему написать все на плюсах не удается. Пытон выбран просто потому что он уже интегрирован. И дело собсно не в нем - нужно придумать "свой язык" для решения разнообразных задач комбинирования анимаций. Ну или скромнее/реалистичнее "свoе API"

Возможно, что именно у вас и не получается. Или я просто не понимаю, в чём именно проблема то? Если вам так уж нужны именно скрипты, то в Ot JS есть...

Проблема в том "а что (или как) писать на скриптах ?"

Так вы определитесь, что в вашем понимании сама "анимация". Можкт у вас это всего лишь 100500 статичных картинок. :)
Т.е. "плясать" надо от самой задачи. А вы пытаетесь начать от ЯП.
Хотя, если шибко хочется поиграться, то можно попробовать всё писать на пайтоне, а оболочку на том же PyQt.

Почему нет? Анимацией может быть многое, набор спрайтов тоже. Напр первые 100 картинок = "Animation 1", вторые 60 = "Animation 2" и.т.д. В любом случае анимация имеет диапазон кадров/времени и данные для каждого. Эти данные могут "проигрываться" приложением. Но это всего лишь одна анимация. А нужно создать средства для автоматычного проигрывания 2 и более анимаций, как бы "небольшой фильм"  :)

Что тут может быть неясно, и откуда такая "стена непонимания" - хз

"Дьявол скрывается в деталях". Оно, ведь только абстрактно "всё просто и понятно".
Я ни на что не претендую, но попробуйте написать ТЗ на такую задачу. Хотя бы для себя. Только полное. Т.е. на чём все это должно запускаться, в каких условиях и т.д.

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

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

Ну так и начните разрабатывать. Сомневаюсь, что найдётся лох, кто подобное будет делать нахаляву.
Хотя: лох - не мамонт, не вымрет! :D
Если подобное заказывать - ТЗ всё равно будет нужно.

1) написать аналогичный тестовый код на С++
2) определить его ключевые элементы: какие классы и объекты используются
3) создать к ним питоновские привязки (по-моему один из вариантов — SWIG)
4) переписать 1) на питоне для верификации

не знаю, может поможет подобное из другого проекта (понятия не имею как оно работает):
- https://github.com/xbmc/xbmc/tree/master/xbmc/interfaces/swig
- https://github.com/xbmc/xbmc/tree/master/xbmc/interfaces/python
- https://github.com/xbmc/xbmc/tree/master/tools/codegenerator

Прибегаете к дешевым приемам
Такой упрек можно бросить любой теме

Если заказывать - то нужна хоть какая-то надежда на "сасес" :) А из нашего обсуждения она даже меньше нуля  :)

Спасибо за ссылки, но (как я понял) они посвящены интеграции пытона. Это давно есть (PyQt, спасибо sergek). И небольшой, минимальный опыт создания API на пытоне (для др целей). Трудности 100% "идейные"

Ну хорошо, давайте попробуем, вот вверху описана простая сцена "стадион, гол!! (штангв)". Или предложите др, нет проблем. Что писать? И у меня как-то  в голове совсем пусто.

Такое иногда бывает. Помню в школе писал сочинение "Осень". Начал бодро
Эти неск фраз я где-то слышал. Но дальше - я не могу придумать ничего. Совсем. Включив логическое мЫшление я еще дописал
Хотя понимал что учительнице это не понравится. В общем - тупик

и как писать, словами? :) никто кроме вас ваш код не видит, что в нем доступно — неизвестно.

Можно было еще ж написать, что "почало падаты лыстя, та поховолыся билкы та дятлы" :)

Просто есть впечатлнение (опять же, из нашего разговора), что вы сами не осознаёте, что именно вам надо. Я потому и затеял разговор за ТЗ.
Нормальный ТЗ как раз и предполагает, что заказчик точно знает, что он хочет. И знает, как это проверить.
А вариант "хочу, шоб было круто" - чаще всего означает, что работа:
1) никогда не будет закончена (ибо условия будут меняться на лету)
2) достойна не будет оплачена (в последний момент появится какая-нибудь "хотелка", которая приведёт к полному переписыванию кода (или к существенной его переработке).
Просто задача довольно обширная. Несколько операционных систем (если упоминать Qt), несколько движков игр (если анимации делать именно для игр), несколько языков программирования (допустим в Qt c++, а в unity c#). Соответственно или корректные переходники, или дикие костыли. Ну, либо можно поиграть в национальную русскую забаву "каша из топора". :)

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

А вот это неплохая мыслишка. Хорошо, пусть что-то сделано, как это проверить/оценить? Наверное так: исполнитель должен предъявить код на созданном API который обеспечивает анимацию 3-4 заранее известных сцен (стадион и др). Если это работает, то в присутствии заказчика исполнитель (напр в течение часа) пишет код на API для пары задач заранее подготовленных заказчиком, но исполнителю заранее неизвестных. Чтобы было ясно чего стоит созданное API или так, захардкодил.

Разумеется всегда можно придумать такую сцену что никакое API не потянет  :) Или скрипт окажется слишком сложным. Ну как видно из примеров выше речь идет о простых случаях. Доклепаться конечно можно и тут (а что такое "просто"?), но в конце-концов какое-то "понимание" между заказчиком и исполнителем должно быть всегда

Писать псевдокодом. Никакого кода у меня пока нет, что доступно - надо решать. Есть приложение на плюсах, оно располагает предметом анимации (character) и набором именованных анимаций для него (напр idle, walk, run, jump). Кадр за кадром приложение вызывает скрипт который должен вернуть имя текущей анимации и ее (локальный) кадр. Все, дальше приложение разберется, на экране char напр побежал.

Таким образом скрипт имеет по меньшей мере "object" и доступ ко всем его анимациям. Разумеется если в скрипте мы хотим "реагировать на событие", то скрипт должен иметь ф-ции проверки этого события. Ну это не проблема, подобное уже делал.

А вот какие методы должен иметь object в скрипте - большой вопрос, собсно это и есть предмет разработки.

Должно быть полное соответствие ТЗ. Если уж совсем "по-взрослому", то к ТЗ должен прилагаться "протокол испытаний".
С границами возможных отклонений в качестве ПО. Ну и со штрафами разработчику, если он косячит. И с жестким дедлайном.
А "код на созданном АПИ" - это уже будет совсем отдельная работа, за совсем другие деньги.

Я не предлагал эту работу, во всяком случае пока, поэтому разговоры о ТЗ и деньгах, мягко говоря, преждевременны.

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

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

Давайте. Я про ТЗ говорил не в свете "заряжания бабулек", а в свете понимания масштаба задачи.
Совершенно понятно, что анимации используются не только в играх. Также понятно, что в силу отсутствия некоего общего API для подобных вещей, каждый разработчик пилит свой велосипед для решения этой задачи.
Я вот, пока, даже не представляю себе такой "комбайн" для решения этой задачи "в общем". Хотя, штука может быть весьма популярной, если её удастся осуществить. Но, даже если представить 4 ОС и с десяток движков (если смотреть на игры, к примеру), то API будет просто гигантским. Впрочем, возможно, что я и ошибаюсь...

Попробуем с чего-то начать. Давайте плясать от того "какой скрипт должен написать юзер", учитывая что он вовсе не горит желанием учить какие-то скрипты, поэтому чем меньше ему писать - тем лучше. Та же сцена "стадион-гол" (не вижу др предложений), думаю идеальным вариантом было бы
Задумка: метод set_next_anim автоматычно находит путь в графе от текущей анимации до "apploud" и помещает все найденные по дороге анимации на стек, дальше они тупо плеются. Конечно копаться в графе на пытоне нафиг надо, это на плюсах, со всеми удобствами, напр привлекая QStateMachine

Да, но что должно проигрываться дj кадра 100 и после того как кончится "apploud"? Нагружать этим скрипт никак не хочется. А не свалиться ли в "default"? Т.е. если текущая анимация кончилась и стек пуст - идем на default анимацию. А назначим дефаулт а приложении, там все равно список анимаций юзеру придется заполнять. А из скрыпта может дадим доступ.

Круто (червона рута)? Ну пока хватит, а то выходит "монолог" :). Критикуем, улучшаем, предлагаем

Вы с кода начинаете. А надо с плана.
Понятно, что хочется открыть IDE и начинать "кодить", но так, обычно, ничего не выходит.

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

Продолжим, немного усложним задачу: юзер хочет нечто типа "волны", т.е. когда забили гол, сначала встают болельщики передних рядов, потом более дальних и.т.п.  Как это сделать скриптом ?

[off]Ну это точно ппц, дальше нравоучений дело не уйдет. Блин, ну хоть бы раз ошибиться   :'([/off]

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

Ну это слишком пошло/банально, для простоты считаем что это всем ясно.

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

Ну а если "не так просто"? Перед работой я пью чай, курю и смотрю в окно, во дворе обычно летает десятка полтора голубей. И они совсем не "глупые птахи" чтобы все время крыльями хлопать - они машут при наборе высоты. А при снижении они "планируют", хотя в обоих случаях бывают редкие исключения (выглядят красиво).

Ну хорошо, юзер заготовил 2 короткие базовые анимации "flap" (взмах), и "plane" (планирование). Есть траектория движения (контейнер пар "номер кадра + позиция") и есть номер текущего кадра. На основании этой траектории нужно вычислить какую анимацию заряжать следующей (flap или plane). Как это сделать в скрипте?

Конечно "задача смешная", но проблема в том что нет никакой "матчасти" к которой можно привязаться.  Напр
При этом почему-то совсем не приходит в голову что если у кого-то хватило ума расписать - то тем более хватит реализовать.

Др трудный момент - делать такие гибкие ф-ции API которые могли бы юзаться в др задачах. Как уже говорил, с этим пока напряженка. Напр взлет/посадка (тех же птичек) - пока нет идей. Ах, ну да
:) Да, ну что поделать, задача такая, типа "динамическая" (не путать с динамическим программированием). Так редко, но бывает