Как стать автором
Обновить

Комментарии 16

Интересно, а можно так переместить объект из точки А в точку Б, чтоб всё блурилось… Тогда перемещение по ключевым кадрам круто бы смотрелось :)
Если речь о контролах внутри окна, не вижу ничего сложного — в том же редакторе Shazzam есть пример шейдера DirectionalBlur, который создаёт эффект быстрого движения. Правда, в нём задаётся только направление и скорость движения. Идеальный шейдер должен, наверно, уметь искривлять размытый след по трём точкам, чтобы можно было двигать объекты по нелинейным траекториям.
А если хотите анимировать таким образом движение окон, тут всё сложнее. WPF не умеет рисовать за пределами окна, поэтому нужно позиционировать окно так, чтобы оно вмещало не только собственно элементы окна, но и след от движения, что уже не так тривиально.
Как мне кажется если ваше изображение имело бы прозрачную границу в несколько пикселей, то Motion Blur по краю затемнял бы изображение, так как цвет смешивался с прозрачными (обычно чёрными) пикселями изображения.

Для исправления этого может понадобится добавить проверку на прозрачность и находить средние значение только для непрозрачных пикселей на прямой.
Проверил, затемнения нет. Равно как нет и засвета на тёмных картинках и обрезанной рамкой. Так что всё ок. Не могу объяснить такое поведение шейдеров — не спец :)
Левая картинка выглядит тормозящей, правая искусственно смазанной, при прочих равных правая приемлимее. Но ведь в реальных условиях слева fps должен быть выше (или оно уже учтено?). // Впрочем, к сути статьи это не имеет никакого отношения.
К сожалению, это проблема софта, который я использовал для записи gif-анимации. На сколько я понял, там было выставлено ограничение на минимальную задержку между кадрами равную 0.06 секунд. В описании программы было написано, что это минимально возможная задержка для современных браузеров. В демо-программе всё работает быстрее, и смазанность практически не видна.
Основная ценность статьи для меня, это не motion blur, а работа с шейдерными эффектами.

Да и на гифке не очень хорошо заметно, может лучше было бы сделать видео? Побольше кадров.
А есть ли на платформе WP ограничение на частоту кадров?
Если нет, то лучше в 2 раза увеличить частоту отрисовки анимации и глаз сам будет видеть размытие, самое естественное и правильное
Оконная подсистема Windows основана на очереди сообщений и разгребает их с такой скоростью, которая только возможна на данном железе. Я бы с радостью увеличил частоту отрисовки в 2, 10, 100 раз, да только кто ж мне позволит? :)
У WPF своя очередь. По умолчанию FPS равен 60, к слову.

Этот FPS иногда наоборот приходится снижать, чтобы CPU не проседал из-за графических ненужностей.
FPS у WPF по умолчанию равен 60. Если FPS меньше, значит, отрисовка тормозит.
Насчёт своей очереди знал, а вот насчёт 60FPS нет, спасибо. Да, отрисовка из примера на моём железе происходит медленнее, чем 60 раз в секунду, не зависимо от того, включен Motion Blur или нет. Видимо, дело в RenderTransform.
На мой взгляд, повсеместно такой эффект лучше не использовать (мне кажется, меня бы затошнило, если бы на экране постоянно была такая муть). А вот для привлечения внимания и усиления эффекта — вполне. Сразу создается впечатление, что окно не просто появилось, а прямо так «БАБАХ!» появилось =) И не нужно спрашивать мнение людей напрямую, роль у подобных эффектов — воздействовать на подсознательном уровне.
Извиняюсь, если уведу разговор в иное русло.
Я, как специалист в компьютерной графике, анализирую движение и анимацию.

Реалистичность, или привычность движения очень зависит от анимации. В вашем примере у вас нет причинно следственной связи в анимации обьекта. А именно — он двигается постоянно равномерно. Это очень скучно почти всегда. Тогда как — он должен выскочить, затормозить и затухать. Это почти всегда 3 разные фазы.

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

Нет под рукoй инструментов, чтобы сконвертить в gif, извините.
С мошн Блюром Без мошн Блюра.
Спасибо за комментарий. Собственно, функция ElasticEase, которую я использовал для анимации, ведет себя именно так, как в ваших примерах. Она параметризуется количеством осцилляций, и в моём примере оно равно единице. Если его увеличить, то получится как раз как у вас. Я пробовал ставить большие значения, но мне показалось, что анимация становится слишком навязчивой, хотя это дело вкуса, конечно.
А я как человек, который ещё и ПОЛЬЗУЕТСЯ программами (в отличие от некоторых, которые их только пишут), говорю, что мне науй не нужно, чтоб каждая мулька грузила комп своими окошками с моушнблуром.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории