Решения для 2D-размытия в движении

Я подумываю добавить размытие движения в свою 2D-программу, но сомневаюсь в результатах моего текущего алгоритма.

Мой подход выглядит так на данный момент:

  • Отрисовка в резервный буфер.
  • Когда пришло время обновить передний буфер, смешайте задний буфер с передним буфером.
  • Повторение

То, что может вызвать эффект «размытия движения», очевидно, является смешиванием, поскольку движущиеся объекты оставляют затухающий след.

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

Существуют ли какие-либо решения, которые позволяют мне делать это более эффективно или дают более привлекательный результат?


person Skurmedel    schedule 03.07.2009    source источник


Ответы (3)


На самом деле вы должны рендерить много промежуточных кадров и смешивать их в один результат. Скажем, например, что ваша выходная частота кадров составляет 50 кадров в секунду. Вы, вероятно, получили бы разумный результат, если бы вы выполняли внутренний рендеринг со скоростью 500 кадров в секунду и смешивали группы из десяти кадров вместе, прежде чем показывать это пользователю.

Подход, который вы используете в данный момент, имитирует постоянство, как если бы вы выполняли рендеринг на старую ЭЛТ с медленным люминофором. На самом деле это не то же самое, что размытие в движении. Если продолжительность вашего кадра составляет 20 мс (1000/50), то кадр с размытым движением состоит из рендеринга, охватывающих продолжительность кадра 20 мс, все с одинаковым альфа-взвешиванием. Решение для персистентности состоит из рендеринга 20, 40, 60, 80, 100 мс назад, постепенно исчезающих.

person Andrew Bainbridge    schedule 03.07.2009
comment
Это хорошее предложение, однако похоже, что оно может потребовать много вычислительной мощности. - person Skurmedel; 06.07.2009
comment
Верно. В зависимости от типа примитивов, которые вы визуализируете, возможно, вы могли бы применить некоторые оптимизации. Или вы можете попробовать гибрид моего предложения и вашего. Алгоритм, который вы предложили, был стандартным демонстрационным приемом кодирования еще в 90-х годах. Это может дать хорошие результаты. Однако, если вы ищете универсальную, простую и быструю реализацию размытия в движении, вам не повезло. Вот почему вы почти никогда не видите его реализованным. - person Andrew Bainbridge; 07.07.2009

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

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

person Goz    schedule 03.07.2009
comment
Я должен добавить, что даже этот более красивый план будет выглядеть неправильно, если между кадрами объект не будет двигаться линейно. - person Goz; 03.07.2009
comment
Спасибо. Это интересная мысль, Гоз, я не подумал об этом. Это может выглядеть странно, если объект перемещается от одного конца экрана к другому за один кадр, если непрозрачность заднего буфера низкая. - person Skurmedel; 03.07.2009

Он может быть совсем не резким. Все зависит от используемой функции смешивания. Например, 0,1/0,9 для предыдущего/текущего изображения соответственно обеспечат слабый след.

Я мог бы добавить, что это, по сути, то, как выполняется размытие движения в OpenGL (через буфер накопления)

person EFraim    schedule 03.07.2009
comment
Спасибо за отзыв. Приятно осознавать, что моя идея не была слишком дилетантской :) - person Skurmedel; 03.07.2009