Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BBC BASIC raytracer in 432 characters

mastodon.me.uk

Post reply on HN
Print view View original

41–50 of 96 posts

Re: BBC BASIC raytracer in 432 characters

#41

Post by kragen »

flohofwoe wrote: post #29
ManuelKiessling wrote: post #9

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”?

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/

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

Re: BBC BASIC raytracer in 432 characters

#42

Post by kragen »

Sharlin wrote: post #27
Sharlin wrote: post #16

Earlier quoted context omitted.

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.

…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…

these comments were extremely helpful, thank you

Re: BBC BASIC raytracer in 432 characters

#43

Post by kragen »

ManuelKiessling wrote: post #9

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 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
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

Re: BBC BASIC raytracer in 432 characters

#44

Post by Sharlin »

kragen wrote: post #36
sp332 wrote: post #14

Earlier quoted context omitted.

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.

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

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

Re: BBC BASIC raytracer in 432 characters

#45

Post by kragen »

Sharlin wrote: post #44
kragen wrote: post #36

Earlier quoted context omitted.

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

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 -…

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

Re: BBC BASIC raytracer in 432 characters

#46

Post by londons_explore »

In 398 characters, I can give it error diffusion dithering capabilities, which makes the code smaller and the output quality a bit better:

https://bbcmic.ro/#%7B%22v%22%3A1%2C%22program%22%3A%22MODE1...

It would look even better with bidirectional error diffusion, but that requires reading back memory which I don't know how to do.

Re: BBC BASIC raytracer in 432 characters

#47

Post by alphabetter »

kragen wrote: post #23
mavhc wrote: post #22

Earlier quoted context omitted.

The OP's code has REM based assembly it in to save space

is that assembly or is that the dithering table

Yes, the REM is the lookup table used in line 70.

Because BBC Basic had a built-in assembler it was pretty uncommon for BBC programs to inline machine code as raw data (unlike some other computers from BITD).

Re: BBC BASIC raytracer in 432 characters

#50

Post by [deleted] »

PlunderBunny wrote: post #25
PlunderBunny wrote: post #17

Earlier quoted context omitted.

I'm running this on a BBC micro emulator running at period-accurate speed, and it's taking just under a minute to draw one line. So I think it's going to finish in about 4 hours, which would make sense - approximately twice as fast as the Acorn Electron.

Update: Finished in only 2 hours 30 minutes.

[deleted]
Post reply on HN