Does it make sense to use Vertex Buffer Objects even when changing the Model View matrix?

Question

I'm looking to get some additional performance (FPS) increases on my iPhone App. I'm already using interleaved data, GL_SHORT and a single texture atlas. See this question for details of what I've already done.

Now I want to look at using VBOs to increase performance. According to Apple's OpenGL ES documentation this is a good step to take. However, it does not address how (or if) VBOs are affected by changes to the Model View matrix. Essentially, I have the same object rendered to the scene multiple times, but each time using a slightly different Model View matrix. The main difference between the objects (other than position in the scene) is texture mapping. They all have slightly different texture coordinates.

Will VBOs help in this situation? Should I allocate a separate VBO for each individual object?

Update 1

So far it looks like VBOs have a negative affect on my performance. FPS dropped back into the mid to high 20's. I'm allocationg 70 VBOs: 35 for the data and 35 for indices. I could knock this down to 35 for the data, and one global index array. I'm using glBufferSubData() to update texture coordinates as necessary.

Another thought is to break out all the static data and specify GL_STATIC_DRAW for that VBO.

Was your before-and-after performance assessment done on the iPhone 3G or the iPod touch? I wouldn’t expect a change in framerate from moving to VBOs on older devices, but on GPUs with hardware VBO support, partial updates to a buffer object can cause extra work or synchronization in the driver if the GPU hasn’t finished reading from it. The emphasis here is on “partial”—if you replace the data completely (i.e. with glBufferData), drivers can usually take care of double-buffering for you. — Pivot, Dec 12 '09 at 09:02
Interesting. I’d recommend comparing the two versions in Shark to see where the difference in time is. If the data copy is problematic, another way to update a buffer object is to map it into memory via the `OES_mapbuffer` extension and generate data directly into it. The same caveats for partial updates on GPUs with hardware VBO support apply, since you’re allowed to map a buffer and change only a piece of it, but you can signal that you don’t care about the old contents by calling glBufferData with a null pointer before you map it. — Pivot, Dec 12 '09 at 21:40

prideout · Accepted Answer · 2009-12-13T20:03:06.130

it does not address how (or if) VBOs are affected by changes to the Model View matrix

The model-view transform takes place on the GPU every time you make a draw call. Changing the model-view does not cause the VBO to mutate.

The main difference between the objects (other than position in the scene) is texture mapping. They all have slightly different texture coordinates.

Sounds like you should be adjusting the texture matrix, in addition to the model-view matrix, sorta like this:

glMatrixMode(GL_TEXTURE);
// glTranslate, glRotate, etc
glMatrixMode(GL_MODELVIEW);
// glTranslate, glRotate, etc

Leveraging VBOs is usually a good idea, but they really only help with third-generation iPhones. They don't help much with older iPhones.

Should I allocate a separate VBO for each individual object?

It's usually more efficient to reduce the number of VBOs in your application. Rather than making multiple calls to glBindBuffer, you can supply unique offsets every time you call glDrawArrays or glDrawElements.

Does it make sense to use Vertex Buffer Objects even when changing the Model View matrix?

1 Answers1