[6mian]

If you want to play with ray tracing implementation, it's surprisingly easy to write one by yourself. There's a great free book (https://raytracing.github.io/books/RayTracingInOneWeekend.ht...) or, if you know a bit of Unity a very nice GPU-based tutorial (https://medium.com/@jcowles/gpu-ray-tracing-in-one-weekend-3...). The Unity version is easier to tinker with, because you have scene preview and other GUI that makes moving camera around so much easier. There are many implementations based of these sources if you don't want to write one from scratch, although doing so is definitely worth it.

I spent some great time playing with the base implementation. Making the rays act as particles* that bend their path to/away from objects, making them "remember" the last angle of bounce and use it in the next material hit etc. Most of them looked bad, but I still got some intuition what I was looking at. Moving the camera by a notch was also very helpful.

A lot of fun, great for a small recreational programming project.

* Unless there's an intersection with an object, then set the maximum length of the ray to some small amount, then shoot many rays from that point around and for each hit apply something similar to the gravity equation. Of course this is slow and just an approximation, but it's easy and you can implement a "black hole" type of object that will bend light in the scene.

[kragen]

when i wrote my very first ray tracer it didn't take me an entire weekend; it's about four pages of c that i wrote in one night

http://canonical.org/~kragen/sw/aspmisc/my-very-first-raytra...

since then i've written raytracers in clojure and lua and a raymarcher in js; they can be very small and simple

last night i was looking at Spongy by mentor/TBC https://www.pouet.net/prod.php?which=53871 which is a fractal animation raytracer with fog in 65 machine instructions. the ms-dos executable is 128 bytes

i think it's easy to get overwhelmed by how stunning raytraced images look and decide that the algorithms and data structures to generate them must be very difficult, but actually they're very simple, at least if you already know about three-dimensional vectors. i feel like sdf raymarching is even simpler than the traditional whitted-style raytracer, because it replaces most of the hairy math needed to solve for precise intersections with scene geometry with very simple successive approximation algorithms

the very smallest raytracers like spongy and Oscar Toledo G.'s bootsector raytracer https://github.com/nanochess/RayTracer are often a bit harder to understand than slightly bigger ones, because you have to use a lot of tricks to get that small, and the tricks are harder to understand than a dumber piece of code would be

[dahart]

> when i wrote my very first ray tracer it didn't take me an entire weekend

It’s just a catchy title. You can implement the book in an hour or two, if you’re uncurious, or a month if you like reading the research first. Also maybe there are meaningful differences in the feature set such that it’s better not to try to compare the time taken? The Ray Tracing in One Weekend book does start the reader off with a pretty strong footing in physically based rendering, and includes global illumination, dielectric materials, and depth of field. It also spends a lot of time building an extensible and robust foundation that can scale to a more serious renderer.