Optimize drawing "different" sprites in OpenGL ES 2.0 (batching?)

Question

I started experimenting with OpenGL ES 2.0, and I'm trying to figure out a way to optimize/batch sprite drawing, where sprites only have the texture in common, but differ in the following properties:

• Position
• Size
• Rotation
• Texture coordinates
• Color
• Hue

I tried two different approaches, which are "good enough" for most games, but I'm still curious on how I could optimize drawing sprites further. All the code is available here on GitHub, but I'll explain my approaches below.

(Both approaches use 4 vertices + 6 indices to draw a quad.)

1. One drawcall per sprite.

   Position and texture coordinates are passed as a vec4 vertex attribute. The MVP matrix (that handles size and rotation) is passed as a mat4 uniform. Color is passed as a vec4 uniform and hue is passed as a float uniform.

   Since pretty much everything is being passed as an uniform, I have to set all uniforms and call glDrawElements once per sprite.

   I can draw 50000 sprites at 60FPS on my desktop (i7 2400k, GTX 970).

2. One drawcall per N sprites.

   The second idea I had and tried was dividing sprites in batches of N. In this approach, everything is passed as a vertex attribute.

    attribute mat4 a_projection_view_model;
    attribute vec4 a_pos_tex_coords;
    attribute vec4 a_color;
    attribute float a_hue;
   

   From my tests it seems slightly faster than the previous approach, but it isn't a big improvement. Also, passing the same mat4 and the same vec4 (a_color) four times seems weird and unnecessarily expensive.

   I couldn't figure out a different solution since every sprite has its own MVP matrix, color an hue.

How is sprite batching (when the texture is the same) usually done? Are my approaches "correct" in theory, or am I doing something which is considered bad practice?

How can I optimize my sprite drawing?

Answer 1

The typical situation is that all sprites are rendered with the same view/projection matrices (same "virtual camera").

So the way I see it, all your sprites need just one draw call - just generate all the vertices on the CPU:

• Multiply vertex positions of each sprite with the model matrix
• Pass view*projection as MVP matrix
• Calculate final color for the sprite on CPU, write it to each vertex (so color becomes a vertex attribute)

P.S.

I couldn't figure out a different solution since every sprite has its own MVP matrix, color an hue.

Why would you possibly need one MVP matrix for each sprite and color+hue (instead of just color)?

Answer 2

You should probably avoid the first method. One draw call for just four vertexes is suboptimal. It might work on a bulky desktop PC, but will certainly be very slow on a mobile device.

One solution that I have been using as of late and like it, is to generate the 2D vertexes on the CPU-side and pass them to the shader. Each vertex is comprised of whatever shading attributes you may need (tex-coords, color, position, whatnot), then my Vertex Shader is basically just a pass-through. I also convert the 2D vertexes to OpenGL clip space, since I'm already calculating the final vertex position in the CPU, this is a cheap operation, so my typical 2D sprite drawing Vertex Shader looks something like this:

in vec3 inPosition;
in vec2 inTexCoords;
in vec4 inColor;

out vec2 vTexCoords;
out vec4 vColor;

void main()
{
    gl_Position = vec4(inPosition, 1.0);
    vTexCoords  = inTexCoords;
    vColor      = inColor;
}

That avoids the need of supplying different matrices via uniforms, which facilitates batching. My only batching criteria is the texture applied to the sprites, so I only need one draw call per texture. This can be further optimized if you use texture altases to pack small textures into a larger one.

This is similar to the approach proposed by @snake5's answer.