I’m trying to do the classical sphere texturing like this:
u = (phi + M_PI) / M_TWOPI;
v = theta / M_PI;
phi belongs to [-M_PI, M_PI];
theta belongs to [0, M_HALFPI];
The problem I have is the following, as phi approaches M_PI, u approaches 1, then between the starting and final vertices phi = 0, u = 0 and phi ~ M_PI, u ~ 1 the entire texture will be interpolated into. The way to solve this problem is to interpolate with a function that starts and ends in the same value, maybe some candidates:
u = (cos(phi) + 1) / 2;
u = abs(cos(phi));
u = 1 - abs(phi / M_PI);
These make the sphere look really funky. A mirrored texture results.
The other way might be to duplicate a vertex (one for phi=-M_PI, another for phi=M_PI. But really, I hate duplication.
I suppose you go with vertex duplication nonetheless.
If I use projective texture coordinates (projecting from the top of the sphere), the equator of the sphere gets textured rather ugly, as the sphere is almost vertical there.
I believe the link you’ve sent describes a way to texture a sphere. based on the x, y, z coordinates of points belonging to a sphere.
But if you know phi, theta of a point in advance (while producing the points of a sphere, for example), there is no need to calculate them and the procedure described is a waste of CPU time, I think. Further, it still requires duplication of a vertex to get the texture coordinates right.
Does there exist a recipe for u and v, that gives projective-texturing-like results, but handles the equator of the sphere better? Here’s a screenshot looking towards the equator from inside the sphere.
The pole looks fine:
Note: I can’t hide the equator, since it is being reflected below. But, as you can see, it is a skydome application. Maybe a “sky plane” (actually a paraboloid, I think), gives better results? I could also flatten the skydome a bit, giving half of an ellipsoid, which would probably improve the results a little.
EDIT: I think choosing theta more smartly would fix my problems with the equator. I think I need larger theta increases near the equator, not regularly spaced in the [0, M_HALFPI] interval.
I’ve decided to do things differently now and have tossed the geometric progression. Instead, I’ve setup the equations like this:
sin(theta + delta_theta) - sin(theta) = K
I set K to some value (in my case .5 / m), where m + 1 is the number of samples of theta from the interval 0 … M_HALFPI. The last sample is always M_HALFPI.
I then solve the above equation to get delta_thetas and use them to increment theta from 0 onward. This way I avoid the really small and close-to-one-another thetas that the geometric progression produces.
If what I am doing is bad, I’d appreciate a better solution. I’ve read something online about a Mercator projection being used instead of what I’m doing.