# How to calculate reflection vector from point sprite sphere?

So far I achieved building a cube map following this tutorial. Then I drew three points using glDrawArrays(GL_POINTS,0,3) and calculate the normals based on a sphere.

To compute the incoming light direction and hence the reflection vector I need the surface position. My questions are

1. Do I need view-space or world-space coordinates for each fragment?
2. How to compute the surface position for each fragment?
3. What's the difference between computing lighting in view-space vs. world-space?

Forgot to mention that this is the way I compute the Normal for the spheres

vec3 N;
N.xy = gl_PointCoord * 2.0f - 1.0f;
float mag = dot(N.xy,N.xy);
N.z = sqrt(1.0f - mag);
N = normalize(N);

• You might (or not) need to change your (mag > 1.0f) to (mag >= 1.0f) or even slightly smaller (mag >= 0.98f) to prevent crazy reflection/lighting rounding errors when nearing the edges. I'd do it just to be safe with all the different GPUs & drivers out there. – Stephane Hockenhull Dec 26 '14 at 19:27

The surface position is the normal itself multiplied by the size of the sphere (point sprite) plus the sphere origin.

Keep in mind a point sprite is a slice of the sphere at its center and not the surface of it so there will be some slight error due to the perspective projection not being accounted for but that's par for the course when we cheat using point sprites. (It works perfectly for parallel (ortho) projections)

If you look at it closely you'll see issues with the reflection/lighting but it falls into the [close enough] category and wont really be visible on tiny "spheres".

You can fix this but it roughly doubles the shader cost.

Note that this example is quite extreme with the player's nose about 10 cm (3 inches) from the sphere, the further you are the more "parallel" the view gets and the smaller the error is. If this is important then you should probably switch to a regular sphere mesh as the camera gets closer or use a shader with correction but only for those close to the camera.

The situation is complicated further with point-sprites that are off-center:

That said, points sprites are really cool for bullet hell shooters and retro feel, as well as far-away approximations of spheres (planets, stars, boulders, bushes, pack of leaves, etc). Just don't spend too much effort trying to get them to look like perfect spheres in close-up situation the GPU will spend more time on this than with a bunch of simple triangles.

If you want Mario64 retro-feel with giant point sprites you don't need to correct them, and if you need good looking spheres then use point-sprites only for spheres smaller than 32 or even 16 pixels of radius and actual 3D meshes with different levels of details for larger and larger spheres as the camera gets closer.

The reason to use point sprites is that when polygons get smaller than 8x8 pixels a lot of GPUs start to waste huge amount of vertex and pixel shading power due to the way they work. With pixel shader units being grouped in NxM pixels (often 8x8 or 8x4) having to process the full NxM pixels for EACH triangles that might only have 1 to 4 actual pixels. A few GPUs have tricks to help fix this but not all and you're processing a huge number of vertex for a few pixels. I'll stop here on this as its almost off-topic but was worth explaining why point sprites / billboards are still useful.

• So the position in the surface is sphereOrigin + N * sphereRadius? The sphereOrigin is the vertex that is the input in the vertex shader? – BRabbit27 Dec 26 '14 at 19:41
• I am just learning about point-sprites and OpenGL in general. Even if we can cheat with the point-sprite spheres, how should I do it to account for the perspective projection? Do you know a good source that walk you through this? – BRabbit27 Dec 26 '14 at 19:42
• Yes on [sphereOrigin + N * sphereRadius]. The solution to correct for the perspective is to do some Pythagorean math to figure out the point where the side of the circle (a 2D slice of a sphere) forms a 90-degree triangle between the camera, the circle center, and the surface of the circle. See the "Belt problem" or "Pulley-belt problem" ( en.wikipedia.org/wiki/Belt_problem ) which is the same issue but in 2D. There is a further issue that (x,y)/z projection is not a fisheye projection so there's another error when the point "sphere" isn't centered on screen. (will add another picture) – Stephane Hockenhull Dec 26 '14 at 20:00