PDA

View Full Version : classical sphere texturing



ugluk
01-03-2011, 05:46 PM
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.

mobeen
01-03-2011, 07:17 PM
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.
Have u checked this link http://local.wasp.uwa.edu.au/~pbourke/texture_colour/texturemap/
It solves by first looking at the parametric eq. of sphere


// 0 < theta < PI
// 0 < phi < 2*PI
x=rsin(theta)cos(phi)
y=rsin(theta)sin(phi)
z=rcos(theta)

Then introducing the rectangular parameterization with two vars. u,v (0 < u,v < 1) in the eq to get


x=rsin(v*PI)cos(u*2*PI)
y=rsin(v*PI)sin(u*2*PI)
z=rcos(v*PI)

so that changing the value of the u,v parameters we get the whole range for theta and pi.
using the third eq. u can get v as,


cos(v*pi) = z/r
v*pi = acos(z/r)
v = acos(z/r)/pi

Putting the value of v in first eq. u get the value of u as follows,


sin(v*pi)cos(2*pi*u) = x/r;
cos(2*pi*u) = x/(r*sin(v*pi))
2*pi*u = acos(x/(r*sin(v*pi)))
u = (acos(x/(r*sin(v*pi)))/(2*pi))


Hope this helps,
Mobeen

ugluk
01-04-2011, 05:32 AM
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.
http://img255.imageshack.us/img255/5473/snapf.png

The pole looks fine:
http://img3.imageshack.us/img3/8296/snap1b.png

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.

ugluk
01-04-2011, 06:42 AM
You think it's better now? I've used a geometric progression to make theta changes ever larger.
http://img707.imageshack.us/img707/9956/snap2se.png

ugluk
01-04-2011, 03:49 PM
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.