Лучше создать новые VBO или просто поменять местами данные? (OpenGL)

Таким образом, в приложении рендеринга OpenGL обычно лучше создавать и поддерживать буфер вершин на протяжении всего жизненного цикла приложения и просто заменять данные каждый кадр с помощью glBufferData, или лучше просто удалять VBO и воссоздавать его каждый кадр?

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

Я прочитал технический документ Nvidia по VBO, но, поскольку я новичок в opengl, это не имело большого смысла.

Заранее спасибо за и совет


person Xzhsh    schedule 30.07.2010    source источник


Ответы (2)


Поскольку вы создаете совершенно новый набор данных в каждом кадре, документация, похоже, указывает, что GL_STREAM_DRAW – это правильный подход к делу.

person genpfault    schedule 30.07.2010

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

Таким образом, идеальный случай — поместить все необходимые данные рендеринга в VBO один раз, а затем манипулировать ими только с помощью функций OpenGL, таких как матричное преобразование или шейдеры.

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

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

Здесь вы найдете полезные советы и более подробную информацию: Как использовать OpenGL 3.x VBO для визуализации динамического мира?

person Razzupaltuff    schedule 04.08.2010