[ManuelKiessling]

Ok, this is probably a dumb question: I get that the code traces the rays for this scene, obviously — but where is the scene, then? That is, where is the “data” (as opposed to the algorithm) that says “there’s a sphere at coordinates x,y,z with radius r, and here’s the other one, and here’s the checkerboard plane”?

[Sharlin]

It’s mostly implicit. See how the spheres are symmetric about the centerpoint? (Well, almost, the camera is at Y = -0.1.) The (X, Y) coordinates of their centers are simply (-1, -1) and (1, 1), given by the `I = SGN U` variable at the end of line 40. The Z is implicitly zero. Their radius is 1. The plane is basically defined by `P = Y - 2` at line 60.

[Sharlin]

…to elucidate a bit, when tracing the rays on the left side of the image, the sign of u is -1, so we're trying to intersect a sphere at (x-1, y-1, z), and on the right side similarly one at (x+1, y+1, z). This works because none of the left-side rays can even in theory hit the right-side sphere and vice versa. It's a very simple version of space partitioning optimization. And when tracing the reflected rays, we flip the sign of i, because there's no self-reflection – the left-hand sphere can only reflect the right-hand one and vice versa.

[kragen]

these comments were extremely helpful, thank you

[Sharlin]

No problem, this was a fun puzzle to solve =D

[kragen]

sharlin has explained how the sphere coordinates are computed; the checkerboard plane is implemented by converting downward-pointing vectors (where the y-component v is negative) into upward-pointing vectors toward a point in the sky with the right color

    IF V < 0 then P = (Y + 2)/V : V = -V*((INT(X - U*P) + INT(Z - W*P) AND 1)/2 + .3) + .2

then the (palette index of?) the color of the sky is computed from the square root of the y-coordinate of the direction vector as

    GCOL 0, 3 - (48*SQR V) DIV 16

plus a fixed dithering table

[flohofwoe]

The 3D scene is described by formulas instead of data. It's a bit similar to how SDF demos describe a 3D scene by combing shape formulas into a single formula for the whole scene (SDF = signed distance fields).

E.g. see:

https://iquilezles.org/articles/distfunctions/

[kragen]

while i know you didn't say this was using an sdf, i want to point out that it doesn't seem to be using an sdf, just in case anyone is wondering; it seems to be a conventional whitted-style raytracer that computes sphere–ray intersections in closed form by solving the quadratic

[sp332]

  W=1/SQR(U*U+V*V+1)

This makes a sphere. It gets multiplied by two coordinates to make spheres at different places, U and V.

[kragen]

i think this is incorrect, i think that's computing the z component of the initial direction vector of the ray being traced

if you change the initialization of i from sgn u to 1.2 * sgn u you will get an image with the spheres a little further apart

[Sharlin]

Yeah, that's something of a red herring. The actual ray-sphere intersection happens on line 50:

    // sphere_center = (E, F, Z)
    E = X - I 
    F = Y - I
    // solving the ray-sphere quadratic eqn...
    P = U * E + V * F - W * Z
    // discriminant
    D = P * P - E * E - F * F - Z * Z + 1
    // if solution (ie. intersection) exists
    IF D > 0 
      // intersect_point = ray_orig + T * ray_dir
      // this is the closer pt, -P + SQR D is the other 
      T = -P - SQR D

[kragen]

yeah, that was what i guessed it was doing, but i couldn't remember or rederive the ray-sphere intersection formula to be sure