Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

get_sphere_uv does not correspond to its explanation #533

Closed
D-K-E opened this issue May 14, 2020 · 4 comments
Closed

get_sphere_uv does not correspond to its explanation #533

D-K-E opened this issue May 14, 2020 · 4 comments

Comments

@D-K-E
Copy link

D-K-E commented May 14, 2020

The function get_sphere_uv in NextWeek listing 42 at section Texture 6.1, is given as

void get_sphere_uv(const point3& p, double& u, double& v) {
    auto phi = atan2(p.z(), p.x());
    auto theta = asin(p.y());
    u = 1-(phi + pi) / (2*pi);
    v = (theta + pi/2) / pi;
}

whereas in the formula given in the explanation is:

To compute θ and ϕ, for a given hitpoint, the formula for 
spherical coordinates of a unit radius sphere on the origin is:

x=cos(ϕ)cos(θ)
y=sin(ϕ)cos(θ)
z=sin(θ)

We need to invert that. Because of the lovely <cmath> 
function atan2() (which takes any number proportional 
to sine and cosine and returns the angle), we can pass in x
and y (the cos(θ) cancel):

ϕ=atan2(y,x)

The atan2
returns values in the range −π to π, so we need to 
take a little care there. The θ is more straightforward:

θ=asin(z)

which returns numbers in the range −π/2
to π/2. 

The problem also exist in dev-major branch.

@hollasch
Copy link
Collaborator

Thanks for reporting! If you would like, feel free to submit a pull request of your suggested changes to the dev-patch branch.

@D-K-E
Copy link
Author

D-K-E commented May 14, 2020

Sure, very solid work by the way. I am also porting the Weekend version to opengl with compute shaders in here

@D-K-E
Copy link
Author

D-K-E commented May 15, 2020

The PR that was suppose to change the code for implementing the formula above is closed now, because most of the sources I have cited there favor the existing implementation. The wording in this section might be improved to show how we arrive to the implementation of get_sphere_uv function, instead of using unit sphere at origin to represent the problem.

@hollasch hollasch added this to the v3.1.3 milestone Jun 4, 2020
@trevordblack
Copy link
Collaborator

Suggest punting to 3.2

@hollasch hollasch reopened this Jun 24, 2020
@hollasch hollasch modified the milestones: v3.1.3, v3.3.0 Jun 24, 2020
@trevordblack trevordblack modified the milestones: v3.3.0, v3.2.2 Oct 5, 2020
@hollasch hollasch self-assigned this Oct 11, 2020
hollasch added a commit that referenced this issue Oct 12, 2020
Also, get_sphere_uv() is in sphere.h for book 2, but hittable.h for book
3. This change also moves the function to sphere.h for book 3.

Resolves #533
hollasch added a commit that referenced this issue Oct 25, 2020
Fixed in text and code. This addresses the following problems:

- Confusion between UV space and texture image space. There were places
  that assumed Y/V grows, down, others where Y/V grow upwards. Correct
  UV coordinates have Y/V growing upwards, as in regular 2D Cartesian
  coordinates. The V coordinate is flipped for texture-map lookup, left
  alone for all other coordinate uses.

- The Y and Z coordinates were confused in several equations.

- The text had Y = sin(theta), where it should have been
  Y = -cos(theta).

- There was nothing in the text to explain the rearrangment of atan2()
  arguments in order to get a continuous 0->2pi return value. I
  introduced the equivalence formula to get continuous return values.

- get_sphere_uv() was in sphere.h for book 2, but hittable.h for book 3.
  This change also moves the function to sphere.h for book 3.

- get_sphere_uv() moved to be a private static method on class sphere.

- I am used to (and therefore prefer) phi corresponding to latitude, and
  theta corresponding to longitude, where the text and code flip these
  two angles. In a quick search of definitions, it looks like this is
  yet another case of competing conventions with both sides roughly
  equal in size. Thus, no clear winner, so I'm leaving this as is.

Resolves #533
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants