If you want to learn more, the best raytracing book is http://www.pbrt.org/ which goes into immense details about various techniques and won an Academy Award. The renderer described in the book is also available online: https://github.com/mmp/pbrt-v3
Note that the pbrt-v3 code is the updated code corresponding to the soon-to-be-released 3rd edition of the book, but the book available in bookstores is still the 2nd ed. If you like me plan on buying the book soon, you probably want to wait just a little while for 3rd ed which is due any time now.
This looks like a slimmed down version of the book Realistic Ray Tracing writen by the same author Peter Shirley. The book is still very short ~200 pages and develops a raytracer.
He has also written one of my favorite general introductions to computer graphics if your looking for a usable survey text that has most of the basic formulas.
Interesting idea of speed writing... "speed book", "agile book". Removes inertia and barriers to creation. I read through the book (just a skim for _now_). Very well done. I wonder if we will see more of this trend for certain byte-sized topics. (<-- ...see what I did there? )
"Since then I have written a bunch of ray tracers in Pascal, Fortran, Scheme, C, C++, Java, and most recently Swift (which is awesome for writing ray tracers). "
Likely the strong generics while still being terse and inbuilt functional methods on collection types. Also being able to add extensions to any class is super helpful.
I've also been writing a ray tracer in Swift. Would love to look at yours if it's Open Source. The core rendering logic for mine is here[0]. I also started building a .obj loader for Swift[1].
What is the benefit of writing a bunch of different raytracers? Is it just an exercise to practice a new language and reenforce your understanding of raytracing fundamentals, or is there actually a notable difference?
Both the computing tech and raytracing/graphics theory and algorithms have changed significantly over that time, with better algorithms and much more powerful computing resources allowing more brute-force/accurate stuff to be more practically done.
Writing a raytracer/renderer is also rather addictive, and it's quite cool writing something which produces something else (as is writing compilers).
I've written a few over the last 25 years as well, and it's fun to write something that produces pretty pictures -- like drawing or playing an instrument is fun.
Currently I'm doing a C++ one that describes the model, colour handling and animation etc. using the type system directly rather than a traditional class hierarchy. https://github.com/KayEss/AnimRay
Fortran it was for money :). But really the built-in array operations made it surprisingly sweet. The others it was just an excuse to learn the language mostly for fun.
Not at present I am afraid. But I will confess I mainly pushed toward getting it done and went with kindle because I knew that platform. I will do some homework on this.
The sections listed don't cover acceleration structures. Thats critical to performance on scenes of any complexity. Otherwise it looks like a decent introduction.
The latter, it's about getting quick wins, getting up and running as fast as possible, and having enough of a framework and enough fun by the end to be motivated and capable of exploring any of the advanced topics for research or production rendering that might tickle your fancy.
