Architecture for Sprite Rendering in OpenGL
===

I have a lot of sprites to render, and wanted to get any feedback from folks who have pushed performance in this area.

So I sort by shaders and texture. And have batches of sprites with the same render settings in VBOs to send to the shaders for rendering. All normal stuff. My sprites are all square and all have the same basic data: central position (P), orientation (O), scale (S), rgb color (Col) and global opacity (Alpha). I have to update the position and orientation in CPU code, (though about 50% of sprites don't change between any given pair of frames) and scale, color and opacity almost never change for a sprite, but not actually never.

I can't assume geometry shaders (I will support them, but the question is moot in that case).

Should I:

1. When I update the sprite positions, calculate the vertex positions on the CPU. Making the vertex shader a simple transform step. (Advantage of a significantly smaller amount of data to update each frame, but the CPU has to do a lot of trig).

2. Put the POS data into the VBO as additional data, duplicated for the 4 verts, then have the vert position just be simple offsets (-1,-1; -1,1; 1,1; 1,-1) and do the trig in the shader (Advantage that the GPU is doing more calculation, but each vertex has 5 extra words of data).

3. It isn't obvious which is better, so both approaches need profiling to see what happens.

Obviously I can do 3, but I thought it would be useful to ask this question to see if I'm just lacking a gestalt about what should be faster. And either way the answer can help other serious sprite/particle implementers later.


