Ray tracing texture implementation for spheres

Question

I'm trying to implement textures for spheres in my ray tracer. I managed to get something working, but I am unsure about its correctness. Below is the code for getting the texture coordinates. For now, the texture is random and is generated at runtime.

virtual void GetTextureCoord(Vect hitPoint, int hres, int vres, int& x, int& y) {
    float theta = acos(hitPoint.getVectY());
    float phi   = atan2(hitPoint.getVectX(), hitPoint.getVectZ());

    if (phi < 0.0) {
        phi += TWO_PI;
    }

    float u = phi * INV_TWO_PI;
    float v = 1 - theta * INV_PI;

    y = (int) ((hres - 1) * u);
    x = (int) ((vres - 1) * v);
}

This is how the spheres look now: enter image description here

I had to normalize the coordinates of the hit point to get the spheres to look like that. Otherwise they would look like:

enter image description here

Was normalising the hit point coordinates the right approach, or is something else broken in my code? Thank you!

Instead of normalising the hit point, I tried translating it to the world origin (as if the sphere center was there) and obtained the following result:

enter image description here

I'm using a 256x256 resolution texture by the way.

Is hitPoint always computed as if the sphere is at the origin (and then transformed elsewhere), or are you directly supporting non-origin-centered spheres in your intersection test? Computing phi and theta using cosine and tangent gives you values corresponding to a sphere centered at the origin, so if the sphere actually isn't, the texture coordinate mapping won't be what you probably intended. — Wyzard
BTW, u and v are the texture coordinates, and a function for computing texture coordinates would typically just return those. Mapping them to integer texel indexes isn't specific to spheres, and should be done elsewhere. — Wyzard
I had a similar problem when I was generating textures at runtime for a real-time hatching algorithm. My mistake was to calculate the texture coordinates in world space, while they need to be considered in local space. hitPoint is in world/view or local space? — codingadventures
I think I am directly supporting non-origin-centered spheres in the intersection test. Is there a way arround this? — ionutt93

Wyzard Wyzard · Accepted Answer · 2015-04-17T13:34:35

It's unclear what you mean by "normalizing" the hit point since there's nothing that normalizes it in the code you posted, but you mentioned that your hit point is in world space.

Also, you didn't say what texture mapping you're trying to implement, but I assume you want your U and V texture coordinates to represent latitude and longitude on the sphere's surface.

Your first problem is that converting Cartesian to spherical coordinates requires that the sphere is centered at the origin in the Cartesian space, which isn't true in world space. If the hit point is in world space, you have to subtract the sphere's world-space center point to get the effective hit point in local coordinates. (You figured this part out already and updated the question with a new image.)

Your second problem is that the way you're calculating theta requires that the the sphere have a radius of 1, which isn't true even after you move the sphere's center to the origin. Remember your trigonometry: the argument to acos is the ratio of a triangle's side to its hypotenuse, and is always in the range (-1, +1). In this case your Y-coordinate is the side, and the sphere's radius is the hypotenuse. So you have to divide by the sphere's radius when calling acos. It's also a good idea to clamp the value to the (-1, +1) range in case floating-point rounding error puts it slightly outside.

(In principle you'd also have to divide the X and Z coordinates by the radius, but you're only using those for an inverse tangent, and dividing them both by the radius won't change their quotient and thus won't change phi.)

Right now your sphere intersection and texture-coordinate functions are operating in world space, but you'll probably find it useful later to implement transformation matrices, which let you transform things from one coordinate space to another. Then you can change your sphere functions to operate in a local coordinate space where the center is the origin and the radius is 1, and give each object an associated transformation matrix that maps the local coordinate space to the world coordinate space. This will simplify your ray/sphere intersection code, and let you remove the origin subtraction and radius division from GetTextureCoord (since they're always (0, 0, 0) and 1 respectively).

To intersect a ray with an object, you'd use the object's transformation matrix to transform the ray into the object's local coordinate space, do the intersection (and compute texture coordinates) there, and then transform the result (e.g. hit point and surface normal) back to world space.

Ray tracing texture implementation for spheres

1 Answers