Comments 10
Попробовал анимацию, всё очень хорошо, но не хватает гибкого управления скоростью воспроизведения. Например, кривой фпс по времени.
И при «пробежке» мышью по кадрам с помощью таймлайна — видны подлагивания при прогрузке.
Если второе скорее всего исправят, то без первого выйдет мертворожденный функционал. Попробую зарепортить свою идею.
И при «пробежке» мышью по кадрам с помощью таймлайна — видны подлагивания при прогрузке.
Если второе скорее всего исправят, то без первого выйдет мертворожденный функционал. Попробую зарепортить свою идею.
Кривую ФПС от времени сделать можно. Я, правда, если честно, нигде такой штуки не видел. Есть примеры? Обычно бывают только инструменты «растягивания» кадров. Их мы обязательно сделаем, сейчас только нужно понять, в каком виде они нужны :) На данный момент растяжение отдельного кадра доступно через Alt+перетаскование.
А про подлгагивания, проверьте, чтобы у вас был включен openGL.
А про подлгагивания, проверьте, чтобы у вас был включен openGL.
Я занимаюсь анимированием мешей с 2D спрайтами в Юнити и там это совершенно естественный функционал, когда ты добавляешь динамики в анимацию регулируя кривую безье, которая показывает зависимость скорости изменения самых разных элементов от времени.
Это так же работает и для покадровой анимации. Например, мы рисуем персонажа, наносящего горизонтальный рубящий удар мечом. В процессе отрисовки кадров сложно передать «паузу», в которой броня врага принимает от меча кинетическую энергию. Так же сложно передать резкое ускорение его тела после этой паузы. Это гораздо проще и естественнее сделать на этапе сведения, когда все кадры готовы и занимают свои места.
Пример с ударом — только частный случай. Есть много других ситуаций, где придется редактировать динамику скорости вывода кадров.
К сожалению у меня не найдется графических примеров в данный момент. Добавлю их когда вернусь с работы.
Сама кривая отлично приживется в таймлайне, где ее можно будет скроллить вместе с кадрами.
Это так же работает и для покадровой анимации. Например, мы рисуем персонажа, наносящего горизонтальный рубящий удар мечом. В процессе отрисовки кадров сложно передать «паузу», в которой броня врага принимает от меча кинетическую энергию. Так же сложно передать резкое ускорение его тела после этой паузы. Это гораздо проще и естественнее сделать на этапе сведения, когда все кадры готовы и занимают свои места.
Пример с ударом — только частный случай. Есть много других ситуаций, где придется редактировать динамику скорости вывода кадров.
К сожалению у меня не найдется графических примеров в данный момент. Добавлю их когда вернусь с работы.
Сама кривая отлично приживется в таймлайне, где ее можно будет скроллить вместе с кадрами.
Присылайте, посмотрю. Идея очень хорошая!
Нарисовал наброски одной тушки, пинающей другую тушку:
В этом случае фпс фиксирован, 0.1с на фрейм:
А уже в случае ниже пришлось обратиться к редактору, который может менять скорость воспроизведения по времени.
Начинается с 0.3 секунд на кадр и плавно ускоряется до 0.1 секунды до момента удара (имитируя разгон вращающейся тушки вокруг оси), затем у оставшихся кадров 0.2 секунды на кадр:
Мне кажется, что константное пфс в анимации отдает мертвечиной.
В этом случае фпс фиксирован, 0.1с на фрейм:
А уже в случае ниже пришлось обратиться к редактору, который может менять скорость воспроизведения по времени.
Начинается с 0.3 секунд на кадр и плавно ускоряется до 0.1 секунды до момента удара (имитируя разгон вращающейся тушки вокруг оси), затем у оставшихся кадров 0.2 секунды на кадр:
Мне кажется, что константное пфс в анимации отдает мертвечиной.
А как GUI выглядит можно скрин? Или ссылку на мануал? И как такие картинки с неровным FPS потом экспортируются? Или он в итоге линеаризуется к наименьшему общему делителю?
Использовался Фотошоп:
Он проставляет скорость вывода отдельно каждому кадру. Это жутко неудобно и заточено, видимо, под экспорт видео и гифок.
Хотелось бы видеть нечто, похожее на кривые из Юнити:
Этот метод хорош всем.
Тем, что дает полную свободу управления FPS'ом, а так же тем, что его можно использовать и для других переменных слоя — таких, как прозрачность, цветность, наклон, что угодно.
Кривые Безье вообще хороши, вершины могут быть любыми, например острыми, передавая резкий импульс увеличения или уменьшения переменной после прохождения изгиба:
Касательно вопроса с экспортом:
Скорее всего придется вставить пустые кадры (не пустые, а копии соседних кадров), чтобы привести значение FPS к одному — для всей анимации.
Не надо вычислять его, пусть оно явно спрашивается с пользователя в окне «Animation»>«Frame Rate», как есть уже сейчас.
И лучше выровнять FPS не на стадии экспорта, когда пользователь ничего не видит, а по нажатию кнопки «Выровнять ФПС». Тогда кривая скорости выравнивается в ровную прямую, Таймлайн разбавляется новыми заглушками, которые пользователь может перерисовать, чтобы получить более плавную анимацию (если Вы обратите нимание, в моем предыдущем посте во 2м примере есть в самом начале обрывистый эффект нехватки ФПС. Вот там было бы идеально навтыкать дополнительных кадров для разглаживания анимации).
Мне интересно узнать, надо ли писать сообщение с реквестом фичи в баг-трекер? Или мои надежды обречены?
Спрашивайте, если что-то плохо объяснил. С радостью отвечу.
Он проставляет скорость вывода отдельно каждому кадру. Это жутко неудобно и заточено, видимо, под экспорт видео и гифок.
Хотелось бы видеть нечто, похожее на кривые из Юнити:
Этот метод хорош всем.
Тем, что дает полную свободу управления FPS'ом, а так же тем, что его можно использовать и для других переменных слоя — таких, как прозрачность, цветность, наклон, что угодно.
Кривые Безье вообще хороши, вершины могут быть любыми, например острыми, передавая резкий импульс увеличения или уменьшения переменной после прохождения изгиба:
Касательно вопроса с экспортом:
Скорее всего придется вставить пустые кадры (не пустые, а копии соседних кадров), чтобы привести значение FPS к одному — для всей анимации.
Не надо вычислять его, пусть оно явно спрашивается с пользователя в окне «Animation»>«Frame Rate», как есть уже сейчас.
И лучше выровнять FPS не на стадии экспорта, когда пользователь ничего не видит, а по нажатию кнопки «Выровнять ФПС». Тогда кривая скорости выравнивается в ровную прямую, Таймлайн разбавляется новыми заглушками, которые пользователь может перерисовать, чтобы получить более плавную анимацию (если Вы обратите нимание, в моем предыдущем посте во 2м примере есть в самом начале обрывистый эффект нехватки ФПС. Вот там было бы идеально навтыкать дополнительных кадров для разглаживания анимации).
Мне интересно узнать, надо ли писать сообщение с реквестом фичи в баг-трекер? Или мои надежды обречены?
Спрашивайте, если что-то плохо объяснил. С радостью отвечу.
Я добавил ссылку на ваш коммент сюда: phabricator.kde.org/T1105
Если сможете нарисовать концепт GUI для Криты и прикрепить туда же, то будет совсем здорово. Тогда реализовать будет намного проще. А так, как нибудь позже займусь.
Если сможете нарисовать концепт GUI для Криты и прикрепить туда же, то будет совсем здорово. Тогда реализовать будет намного проще. А так, как нибудь позже займусь.
думал попробовать под Linux интересная ошибка
Или у вас она на Linux под wine запускается и устанавливаетсья?
Essential application components could not be found.
This might be an installation issue.
Try restarting, running kbuildsycoca4.exe or reinstalling.
Или у вас она на Linux под wine запускается и устанавливаетсья?
Мне кажется, вы не тот пакет установили. Это сообщение было в Крите времен 2.8, а потом его убрали. Появлялось оно, когда были проблемы с установкой и нужно было перезапустить kbuildsycoca4. А так как проблема возникала обычно под виндой, то и .exe приписали. Wine'а никакого конечно же нет :)
В общем, нужно поставить нормальный пакет (если Ubuntu) или собрать из исходников, если не-ubuntu.
В общем, нужно поставить нормальный пакет (если Ubuntu) или собрать из исходников, если не-ubuntu.
Sign up to leave a comment.
Krita 2.9 Animation Edition Beta: первая бета-версия анимации и движка для работы с 10k изображениями