OpenGL ES 2.0 point sprites with distinct rotations - calculate matrix in shader?

Question

I am trying to find a solution that will allow me to rotate point sprites about the z-axis with a varying attribute (i.e. uniform will not do).

In my app I have many hundreds/thousands of point sprites being drawn per frame, which are then stored in VBOs (can quite feasibly end up being >1,000,000). As such, I am looking for the best compromise between memory usage and performance.

Vertex & fragment shaders current look like this:

// VERTEX SHADER
attribute vec4 a_position;
attribute vec4 a_color;
attribute float a_size;
uniform mat4 u_mvpMatrix;
varying vec4 v_color;

void main()
{
    v_color = a_color;
    gl_Position = u_mvpMatrix * a_position;
    gl_PointSize = a_size;
}


// FRAGMENT SHADER
precision mediump float;
uniform sampler2D s_texture;
varying vec4 v_color;

void main()
{
    vec4 textureColor = texture2D(s_texture, gl_PointCoord);
    gl_FragColor = v_color * textureColor;
}

I can currently imagine the following possibilities:

• Add a mat4 rotMatrix attribute to my point sprite data. Pass this to the fragment shader and rotate each fragment:

  vec2 texCoord = (rotMatrix * vec4(gl_PointCoord, 0, 1)).xy
  gl_FragColor = v_color * texture2D(s_texture, texCoord);
  

  • Advantages:
    • Keeps shaders simple.
    • Simple code to compute matrices outside the shaders (using GLKit for example).
  • Disadvantages:
    • Massively increases the size of my point sprite data (from 16 to 80 bytes/point for a 4x4 matrix; to 52 bytes/point for a 3x3 matrix... I believe it's possible to use a 3x3 rotation matrix?). This could potentially cause my app to crash 3-5 times sooner!
    • Pushes a lot more computation onto the CPU (hundreds/thousands of matrix calculations per frame).

• Add a float angle attribute to my point sprite data, then calculate the rotation matrix in the vertex shader. Pass the rotation matrix to the fragment shader as above.

  • Advantages:
    
    • Keeps point sprite data size small (from 16 to 20 bytes/point).
      
    • Pushes the heavy lifting matrix maths to the GPU.
      
  • Disadvantages:
    • Need to write custom GLSL function to create rotation matrix. Not a massive problem, but my matrix maths is rusty, so this could be error prone, especially if I'm trying to figure out the 3x3 matrix solution...
    • Given that this must happen on hundreds/thousands of vertices, is this going to be a serious drag on performance (despite being handled by the GPU)?

• I could realistically cope with 1 byte for the angle attribute (255 different angles would be sufficient). Is there any way I could use some kind of lookup so that I don't need to needlessly recalculate the same rotation matrices? Storing constants in the vertex shader was my first thought, but I don't want to start putting branch statements in my shaders.

Any thoughts as to a good approach?

Answer 1

The solution I went with in the end was the 2nd from the question: calculate the rotation matrix in the vertex shader. This has the following advantages:

• Keeps point sprite data size small.
• Rotation calculations are performed by the GPU.

The disadvantages I guessed at don't seem to apply. I have not noticed a performance hit, even running on a 1st gen iPad. The matrix calculation in GLSL is somewhat cumbersome, but works fine. For the benefit of anybody else trying to do the same, here is the relevant part of the vertex shader:

//...
attribute float a_angle;
varying mat4 v_rotationMatrix;

void main()
{
    //...

    float cos = cos(a_angle);
    float sin = sin(a_angle);
    mat4 transInMat = mat4(1.0, 0.0, 0.0, 0.0,
                           0.0, 1.0, 0.0, 0.0,
                           0.0, 0.0, 1.0, 0.0,
                           0.5, 0.5, 0.0, 1.0);
    mat4 rotMat = mat4(cos, -sin, 0.0, 0.0,
                       sin, cos, 0.0, 0.0,
                       0.0, 0.0, 1.0, 0.0,
                       0.0, 0.0, 0.0, 1.0);
    mat4 resultMat = transInMat * rotMat;
    resultMat[3][0] = resultMat[3][0] + resultMat[0][0] * -0.5 + resultMat[1][0] * -0.5;
    resultMat[3][1] = resultMat[3][1] + resultMat[0][1] * -0.5 + resultMat[1][1] * -0.5;
    resultMat[3][2] = resultMat[3][2] + resultMat[0][2] * -0.5 + resultMat[1][2] * -0.5;
    v_rotationMatrix = resultMat;

    //...
}

Given that there is no noticeable performance hit this solution is ideal, as there is no need to create texture maps/lookups and consume additional memory, and it keeps the rest of the code clean and simple.

I can't say that there are no downsides to calculating a matrix for every vertex (reduced battery life, for example), and performance may be a problem in different scenarios, but it's good for what I need.