Как реализовать VBO для больших сеток и получить плавную анимацию?

Я думаю о 2D-массивах как для вершин, так и для нормалей, по одному для каждого кадра; и

Я думаю, что это неправильное решение. С таким объемом данных имеет смысл его стримить. Например, держать в памяти 1 секунду анимации, остальное подгружать по требованию. Я считаю, что для этого сценария есть GL_STREAM_**** флагов.

Лучшим решением будет экспорт костей из майя и их анимация. (В этом случае вам понадобится один меш, который никогда не изменится)

Единственная ситуация, в которой вам пришлось бы экспортировать покадровую анимацию для каждой вершины, — это когда вы экспортируете что-то безумно дорогое в вычислительном отношении. Единственный реалистичный сценарий, о котором я могу думать, - это 3D-жидкостные сетки (топология меняется в самом кадре и т. д.) - все остальное можно вычислить либо на ЦП, либо на графическом процессоре. Однако в вашем сообщении не указано, что это ваш сценарий. Итак, по закону Мерфи я должен предположить, что вы используете неэффективное решение проблемы, которую можно решить по-другому.

: Будет ли приведенный выше код работать или работать «хорошо» с VBO?

Невозможно ответить, потому что вы не сказали, как вы собираетесь рисовать данные. Можно поставить любую машину на колени даже с простой геометрией, злоупотребляя шейдерами, альфа-смешиванием или рендерингом одного и того же МНОЖЕСТВО раз.

Если бы вы могли плавно запустить два кадра своей анимации, вы могли бы плавно запустить 60 * 24 кадра, «стоящих операторов glVertex и glNormal», если бы вы могли автоматически генерировать вызовы GL из своей анимации Maya. Единственная проблема этого подхода заключается в том, что ваш исходный код и двоичный исполняемый файл будут безумно огромными. Это проблема, которая делает ваш подход «плохим».

Итак, во-первых, вместо одного вызова glVertex для данных каждой вершины вы вполне можете хранить свои данные в массиве (или std::vector, если уж на то пошло) и перебирать их с помощью простого цикла:

std::vector<int> idx;
std::vector<vertex> frame_data;
...
glBegin(GL_QUADS);
for(int i = 0; i < idx.size(); ++i) {
  glVertex3f(frame_data[idx].x, frame_data[idx].y, frame_data[idx].z);
  glNormal3f(frame_data[idx].nx, frame_data[idx].ny, frame_data[idx].nz);
}
glEnd();

Idx представляет грани, каждые 4 элемента в idx образуют четырехугольник. Frame_data — это конкретные данные вершин для этого кадра, у вас должен быть один такой массив для каждого кадра, и эти данные индексируются idx. Таким образом, единственная проблема, которую вам нужно решить, — это как считывать эти данные в ваше приложение. Если вы можете сгенерировать вызовы glVertex из вашего файла сетки, вы могли бы вместо этого сгенерировать файл, который вы можете легко загрузить в свое приложение с помощью C++ fstream, и создать массивы данных, а затем просто перебрать их и выполнить вызовы рисования.

Вы не увидите разницы в производительности между использованием glBegin()/glEnd() и VBO в этом случае, потому что 2200 quads — это слишком мало, чтобы иметь какое-либо значение, но это было бы интересным упражнением для вас. Организация данных в массивах, о которых я вам говорил (idx и vertex_data), — ​​это первый шаг к использованию VBO. Вы должны упаковать все данные относительно одной вершины внутри одной структуры:

struct vertex {
  float x, y, z; // Position
  float nx, ny, nz; // Normal
};
...
vertex frame_data[v_count];
uint16_t idx[2200 * 4]; // 4 vertices makes one face

Обратите внимание, что v_count не 2200. Это количество ваших четырехугольников, поэтому это число относится к размеру idx, а не к frame_data, т. е. одна и та же вершина может использоваться в нескольких гранях четырехугольников.

Вам понадобятся два буфера, один статический для хранения idx (GL_ELEMENT_ARRAY_BUFFER с GL_STATIC_DRAW), потому что он не изменится во время выполнения, и другой «потоковый» буфер для хранения данных вершин (GL_ARRAY_BUFFER с GL_STREAM_DRAW). Последний использует «GL_STREAM_DRAW», потому что вам нужно будет переписывать его содержимое каждый кадр для анимации. См. glBufferData.