Ray trace spheroid needed for Earth

[SkybuckFlying]

Earth is not a sphere but a spheroid.

I need to ray-trace an spheroid.

I think the author can re-derive the formula for a spheroid.

[hollasch]

In our world, the earth is a perfect sphere. And by perfect, I mean within the limits of IEEE 754 64-bit floating point quantization. It has no mass, and therefore no gravity, and therefore does not bend spacetime. It is not a ball, but instead merely an infinitely-thin set of points equidistant from the center. There are no valleys, no mountains, no pits, no hills. It has no ocean, nor does it have an atmosphere. There are no people, no rocks, no cats. No Amazon distribution centers, no inkjet refills, no social media. It does not orbit the sun, nor does it rotate on its own. It does not flex in shape due to the gravity of other bodies in space, regardless of their size or position. (But I have already pointed out its massless nature, so this is redundant). You may orbit this earth, depart it or approach it at any speed you like, as our universe does not dictate any minimum or maximum speed, for light or any other entity. If you speed away from the earth, you will not exhibit any time difference compared to an observer resting quietly on the surface. The surface, by the way, offers no resistance to modification. You can pass through it easily, without effort. Place objects above, below or intersecting with the surface at will. The earth does not care — it is indifferent to you or anything you might do. Our earth is kind of a jerk. A perfectly spherical jerk.

[hollasch]

In all seriousness, though, geodesy is a complicated subject, and there are numerous approaches to approximating the shape of the earth using various formulas. You can use a perfect sphere, an ellipsoid, an oblate ellipsoid, a revolved ellipsoid, a pear shaped surface, and several other approximations, increasing in complexity. For raytracing, you'll need to pick an approximation you like, and reformulate it as an implicit equation so you can solve for ray intersection.

See https://en.wikipedia.org/wiki/Figure_of_the_Earth for a start. Also, https://people.sc.fsu.edu/~lb13f/projects/space_environment/egm96.php gives a good overview of the EGM96 model. Britannica gives a good explanation of the ellipsoid approximation, which is better, but still an approximation: https://www.britannica.com/science/geoid.

[SkybuckFlying]

These datasets:
https://github.com/nvkelso/natural-earth-vector

Assume a WGS84 sphereoid:
https://en.wikipedia.org/wiki/World_Geodetic_System#WGS84

I already noticed that a perfect sphere would need to be scaled in the Y-direction by a low ammount 0,9966472 which can be computed (I forgot how but wasn't that hard to compute just a ratio to compensate), I did this in GLScene which allows for this Y-scaling.

I have no idea how to do this with your raytracer... ???

Without scaling the sphere down to a sphereoid, this WGS84 it becomes noticeable that country lines are slighty off and into the sphere for example... if it's corrected then it's a pretty good fit.

[hollasch]

WGS84 is definitely the most common SRID. Is it really just achieved by a Y-scale? I think there's more to it than that, but I've never really dug into it.

Anyway, let's assume that you can achieve this spheroid by aligning the poles at ±Y and then scaling by (1, 0.9966472, 1). We don't provide a full set of transforms, so what you're missing is a scale class that derives from hittable. Take a look at the translate class (presented in book 2).

You'll see that on entry to the hit function, the input ray is inverse-transformed in order to place it in the object's modeling coordinates. At that point, you perform the intersection with the untransformed object, get the hit geometries (intersection point, surface normal), and then transform them back into world coordinates.

So let's say you have something like this:

class scale : public hittable {
  public:
    scale(shared_ptr<hittable> thing, const vec3& scaling)
      : object(thing), scale_vec(scaling)
    {
        bbox = object->bounding_box() * scale_vec;
    }

    bool hit(const ray& r, interval_ray_t, hit_record& rec) const override {
        // Scale the ray origin and direction by the inverse scaling transform (1/scale_vec.x, 1/scale_vec.y, 1/scale_vec.z).
        // Compute the ray-object intersection.
        // Scale the intersection point and normal by the scale transform.
    }

    ...
}

Now to use this, you would just put scale(make_shared<sphere>(center, radius, material), vec3(1, 0.9966472, 1)) in your scene and trace that. Of course, I'd definitely scale it by (1, 0.5, 1) while debugging to make sure that everything appears to work correctly.

[hollasch]

I'm converting this to a discussion, since it really isn't an issue with the material.

[hollasch]

I have to be honest and admit that I have a nagging thought that scaling the normal may be trickier than a simple multiply. I think that the normal should transform as a covector instead of as a regular vector. Think of transforming a normal not as transforming the vector, but instead transforming the plane tangent to the surface. For example, suppose I have a rubber sheet at 45°. If I stretch it horizontally, the normal points more and more upward. but if I had the normal vector to the sheet, and stretched that horizontally, the vector would point more and more sideways. So I'm pretty sure that the normal vector should be scaled by the inverse transform, while the intersection point is transformed by the unaltered transform. And the incoming ray vector direction? Not sure. I need to get out some paper and pencil and noodle around on this, but not tonight. Exercise for the reader.

[SkybuckFlying]

I hope you can do it, because that would be great, don't leave it to an exercise for the reader, you do it, cause you great ! =D