] OpenGL ES 2.0: поиск советов по производительности / оптимизации VBO для многих движущихся вершин [
] В моей постоянной попытке преобразовать в OpenGL ES 2.0 из ES 1.x я в настоящее время конвертирую некоторый код для использования объектов Vertex Buffer Objects ('VBOs') вместо существующих небуферизованных вызовов glDrawArrays. [
] [] Я настроил VBO и заставил их работать, но столкнулся с дилеммой дизайна и был бы признателен за совет кого-то более опытного в OpenGL ES 2.0. [
] [] Я хочу нарисовать кучу многоугольных спрайтов, которые движутся довольно часто. Это потому, что они динамические тела Box2D, если вы знакомы с Box2D. Каждое из этих многоугольных тел генерируется с помощью GL_TRIANGLE_FAN, что в некоторой степени критично, поскольку GL_POLYGON недоступен в ES 2.0. [
] [] Многоугольники имеют другие атрибуты, такие как цвет, который [] может [] быть изменен на каком-то этапе во время приложения. жизненный цикл, но именно позиции вершин, которые гарантированно меняются почти в каждом кадре. [
] [] Полигоны сгруппированы в игре, поэтому я намерен управлять и рисовать чередующийся массив вершин / цветов для каждой группы, а не для каждого тела, в попытке свести к минимуму обмен данными с графическим процессором. [
] [] Здесь есть несколько путей к успеху, я читал [] руководство по программированию OpenGL ES 2.0 [], чтобы найти как можно больше информации и советов по оптимизации, относящихся к VBO, и вот что они говорят: [
] [] [] [] [
] [- ][
] [] Чередующиеся данные благоприятны, поскольку [] "атрибутные данные для каждого вершина может быть прочитана последовательно "[]. [
][- ][
] [] Книга рекомендует, чтобы []", если подмножество данных атрибута вершины необходимо изменить .. можно .. хранить атрибуты вершин, которые динамический по своей природе в отдельном буфере »[]. [
][- ][
] [] Рекомендуется« использовать GL_HALF_FLOAT_OES везде, где это возможно », особенно для цветов, поскольку местоположения непроецированных вершин могут превышать это требование к пространству. [
][- ][
] [] glMapBufferOES следует использовать, только если весь буфер обновлен, и даже в этом случае операция [] "все еще может стоить дорого по сравнению с glBufferData "[]. [
][
] Вот мои [] вопросы []: [
] [] [] [] [
] [- ][
] [] Если использовать GL_TRIANGLE_FAN в качестве режима рисования, заставляет ли это меня хранить VBO для тела, а не для группы? Или будет общая вершина местоположение, чтобы 'закончить' вентилятор, и текущее тело вызывает рисование нового вентилятора для следующего тела в группе VBO? [
][- ][
] [] Следует ли чередовать все мои данные, несмотря на то, что расположение вершин обновляется с высокой частотой, или мне следует разделить все это / только местоположения в их собственный VBO? [
][- ][
] [] Следуя совету из книги выше, по-видимому, я должен glBufferData расположение моих вершин полностью каждый раз, когда я обновляю рендер, вместо использования glMapBufferOES или glBufferSubData для обновления буферизованных местоположений? [
][- ][
] [] Есть ли какие-либо неупомянутые функции / варианты дизайна, которые я должен использование для повышения производительности в контексте множества движущихся полигонов? [
][- ][
] [] Должен ли я пытаться использовать GL_HALF_FLOAT_OES для хранения цвета, то есть в пространстве 2 с плавающей точкой. Вместо этого я храню 4 числа с плавающей запятой? Если ответ «да», я бы просто использовал любой тип GL, который составляет половину размера GLfloat для каждого цвета, затем побитовое ИЛИ их, затем вставить в соответствующий массив атрибутов? [
][- ][
] [] После того, как я создал X многих VBO, это единственные вызовы, которые мне нужно делать для каждого рендеринга glBindBuffer, glBufferData и glDrawElements / Arrays, или я должен также вызвать glEnableVertexAttribArray и glVertexAttribPointer каждый раз, когда я использую glBufferData? [
][
] Я был бы чрезвычайно благодарен за дальнейшие советы по этому поводу, спасибо. [
]