Должен ли я использовать вершинный шейдер в этой ситуации?

Question

Я хотел бы создать эффект размытия движения путем рендеринга и аддитивного смешивания движущихся объектов в нескольких точках их траектории в течение кадра.

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

Каков мой лучший курс действий? Я решаю между:

1. Сборка данных вершин для каждого подрамника вручную и передать его в ГПУ каждый раз (не нужно будет иметь вершинную программу, если я это сделать)
2. Послать геометрия вместе со значениями скорости. Я могу вычислить промежуточную позицию в вершинном шейдере, хотя я не уверен, как указать, что определенное значение скорости присваивается определенным группам примитивов. Мне нужно будет отправлять одни и те же вершины один раз для каждого подкадрового рендеринга, потому что вершинный шейдер не может создавать новые вершины.
3. Используйте геометрический шейдер для создания всей геометрии для всех подкадров. Я должен иметь возможность получить все подкадры без передачи данных взад и вперед во время всего процесса рендеринга.

Баланс, на который я хочу нанести удар, - это то, что я хочу как минимум избыточную передачу данных, поддерживая как можно больше аппаратного обеспечения. Похоже, я должен использовать объект буфера Vertex для хранения данных геометрии и просто передать несколько мундштуков для отправки данных скорости в вершинный шейдер для каждого рендеринга. Это работает? Также буфер VBO является постоянным, поэтому для достижения наилучшей производительности я должен входить и изменять данные геометрии по мере необходимости, правильно?

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

Есть ли способ, которым я могу предотвратить вызов для каждого отдельного динамического жесткого объекта? Может быть, я мог бы использовать общий атрибут вершины для отправки моей скорости? Это было бы несколько избыточно, потому что у меня мог быть объект с 100 вершинами с одинаковыми данными скорости, но по крайней мере мой шейдер может получить поток этих данных таким образом.

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

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

ОБНОВЛЕНИЕ: см. Расширенную дискуссию по комментариям в отношении того направления, которое было выполнено. Теперь я уверен, что несколько образцов не приведут к хорошему результату из-за «светового эффекта строба»: при некоторых скоростях мне понадобится размытие по соображениям производительности. В этом случае мне нужно накапливать размытые подкадры; рендеринг субкадров, а затем размытие будет по-прежнему оставлять артефакты.

Answer 1

Я хотел бы создать эффект размытия движения при визуализации и аддитивно смешивания движущихся объектов на несколько точек в их траектории в течение кадра.

Это, безусловно, один из способов осуществления размытия движения. Но в наши дни размытость изображения реализуется фильтром постпроцессинга размытия вектора в шейдере фрагментов. См. http://www.blender.org/development/release-logs/blender-242/vector-blur/ для объяснения того, как это работает. Для реального времени процесс должен быть воспроизведен с помощью шейдеров пост-обработки.

Answer 2

1. Программное обеспечение визуализирует подкадры - рассмотрим этот случай «базовый».

2. Vertex шейдер - Вы могли бы это сделать, но не пытайтесь отправить скорость геометрии, просто отправить вершинную скорость:

   Визуализировать рамку к VBO, призывая glVertexAttrib включить текущую скорость и ускорение каждого вершина. Повторно отобразите VBO, указав смещение по времени для каждого подкадра с равномерным значением.

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

3. Geometry shader - Если бы вы пошли с этим, вы могли бы реализовать его так же, как # 2, за исключением того, что вместо этого в шейдере будет реализован «цикл и изменение», что поможет разгрузить больше работы на GPU.

Вы также упомянуть:

• Рендер все с VBO - Если вы использовали РВО/отображения списка, как это вы в основном делать вариант # 1 с большим аппаратным ускорением.
• Проблемы с интерполяцией. Вероятно, вам не стоит пытаться получить точную интерполяцию. Если объекты движутся очень быстро и изгиб, линейная интерполяция скорости (первый порядок), вероятно, прекрасна. Вы можете улучшить его, включая ускорение (второй порядок), но дополнительные заказы или более точную физическую модель, которая может стоить усилий или затрат.
• Возможно, это не стоит - это действительно проблема проблемы. В зависимости от вашего приложения, оборудования и других деталей любое из этих возможных решений может опередить другое. Если производительность важна, вам, вероятно, следует попробовать прототипную реализацию каждого и запустить тесты на целевых устройствах, чтобы увидеть, что лучше всего подходит. (Печальная реальность это, что вы не можете легко выполнять тесты, пока вы уже сделали всю работу.)