I'm currently using OpenTK (OpenGL binding for C#) to draw a lot of points (~17 million) - that very rarely change - in a cube (256 x 256 x 256) with different float "transparency weights".
It pretty much works as intended, but for some reason the frame rate significantly drops if the camera is aligned with a specific axis even though (I think) the work OpenGL has to do is totally independent of the orientation.
The blending mode is SRC_ONE | DEST_ONE | FUNC_ADD and DepthFunc is set to NEVER (because I don't care what's in front or in the back, all that matters is the total sum).
I use a vertex array to store all the "transparency weights" in a float[256*256*256] and use a vertex shader to split the vertexId (0 - 256³) into x, y, z and calculate a color based on those transparency weight and a few settings to control brightness, orientation, etc. via shader uniforms.
Here are a few more details:
Would be great if any of you has an idea or could give me a hint why the framerate drops on one axis and how I could fix that. Thanks in advance.
Update 1:
I think it has to do with that part of the shader (because the "slow") axis changes if I swap x, y, z but I'm still not sure why and how to fix it.
int id = gl_VertexID;
float x = mod(id, 256);
id /= 256;
float y = mod(id, 256);
id /= 256;
float z = id;
vec4 result = vec4(z/256., x/256., y/256., 1.0);
Update 2
Ok, I'm now pretty sure it's not that. I rewrote it to be symmetric like so:
int id = gl_VertexID;
float x = float(id & 0x000000FF) / 1.0000001 / 256.0;
float y = float(id & 0x0000FF00) / 256.00001 / 256.0;
float z = float(id & 0x00FF0000) / 65536.001 / 256.0;
vec4 result = vec4(x, y, z, 1.0);
And it still has performance issues on one axis. My current guess is, that is has something to do with the order of the points returned by the vertex shader.
