Peter Shirley's Raytracing in a Weekend minibooks are another good introduction that goes beyond rendering spheres, and they are now available for free:
Huge endorsement for this one - I’ve been working my way through it and I’ve found that this has helped me level up in my language skills in a way that no other method has so far.
How much of this has actually been written? Can't seem to find any information on current progress beyond the releases section (which notes 4 additional chapters in the last couple months, but little about existing chapters), and googling doesn't immediately turn up any kind progress-blog. I'm not assuming in-order writing, since I've seen other `beta` e-books not follow it (and it often makes sense not to)
So far the pace seems to be about two chapters a month, with the update today bringing the total up to 14. According to the TOC, that only leaves three more to go, plus revision and editing. It is being released in-order - following the author's twitter and screenshots posted there over the past two years, it looks like the content is complete.
I bought the book in beta, chapters 1 - 14 are complete, the last 3 chapters are in progress. More than enough material to keep you busy until the author finishes the last 3 chapters.
TDD is a great approach for a raytracer. They can be absolute nightmares to debug when a minor error in some calculation causes subtle artifacts in your image.
I love the focus on implementation. That really connects the underlying ideas with working code.
For those interested in a gentle introduction to those underlying ideas, including a refresher on the required math, I taught a class on how to implement a ray tracer. All the materials are available: https://avik-das.github.io/build-your-own-raytracer/
I kept variable names roughly the same in order to make it easy to compare the JS version to the Python version. I also translated vector.js to python (for the same reasons), even though you could probably just use numpy directly.
Just so people don't get too hung up on speed issues, please realize that the major advantage with raytracing over rasterization is that it's trivially parallelizable. Naive implementations of ray tracing and rasterization run at O(log n) and O(n) respectively, so at some point in the near future ray tracing (or its optimized version ray marching) will likely win out. See the "Calculation effort" graph mid-page:
Many of the Demoscene demos today use ray marching. Here are some examples of ray marching in WebGL, to show what's possible (and probably inevitable) in the next 5-10 years:
I'm intrigued by the concept of literate programming and interested in exploring options for a Scala project I'm working on right now. It looks like this one was done using Docco [1]. Docco supports Scala, and it appears to be a pretty lightweight approach, largely using Markdown. I'm curious whether any literate programming veterans have tooling they prefer?
It depends on what you are looking for. Docco and friends seem to only be capable of reversing the relationship between comments and code.
However, they don’t allow you to structure the program however you might like independently the need order and _nesting_ of code. In a lot of cases you can get around this through appropriate design patterns.
I’ve recently taken a quite deep dive into possible tools for literate programming. I work with signal processing so code documentation is extremely important but also frustratingly challenging.
There are a lot of “old” tools for literate programming (noweb, FunnelWeb), and they all lack in platform support, but are exceptionally stable and quite pleasant to work with. The more modern “true” literate programming tools are typically using a form of markdown (no links since my notes are not at hand). The last group are the “coffee script style” tools and they seem to be quite popular and active.
It seems to be a case of natural selection for tooling: true literate programming is serverely disadvantaged in terms of IDE/editor support and the programming philosophy is, unfortunate, too different from the norm. Docco styles seems highly pragmatic in contrast.
One option I haven’t tried yet is Emacs’ org-mode which includes true literate programming support. I haven’t found much with regards to real-world usage.
I appreciate the concept of literate programming, however I think this example would be better presented in a 2-column format: All chunks of the program presented in 1 column with accompanying explanations in a second, parallel column. There would be breaks in either column to allow for either the chunk of code or prose to have different lengths.
Then, if desired, one could read the code and/or narrative straight through.
When I was young, graphics programming is what got me to try coding in the first place. At the time, all books I picked up for intros to graphics programming were more about teaching DirectX, and DirectX in the late 90s before IntelliSense was no fun. I found it horribly arcane and ended up a backend/web engineer.
I think if I had better examples like this to follow I would've gotten a lot farther.
I did similar a few years ago, but then after seeing how bad the performance was, I took the exact algorithm and redid it in Java (just for comparison) and the difference in performance astounded me.
To atone for my sins, I also wrote a (free, online) 3D rendering textbook, half of it dedicated to raytracing: http://www.gabrielgambetta.com/computer-graphics-from-scratc...