You are reading a post from a multi-part series of articles
- Ray Tracer in Python (Part 1) - Show Notes of "Points in 3D Space"
- Ray Tracer in Python (Part 2) - Show Notes of "Revealing the True Colors"
- Ray Tracer in Python (Part 3) - Show Notes of "3D Balls in 2D Space"
- Ray Tracer in Python (Part 4) - Show Notes of "Let there be light"
- Ray Tracer in Python - Show Notes of "Ray Tracing a Coronavirus"
- Ray Tracer in Python (Part 5) - Show Notes of "Some Light Reflections"
- Ray Tracer in Python (Part 6) - Show Notes of "Firing All Cores"
Probably a global lockdown is a good time to resume a series that demands a lot of your time. Not really if your kids are home too. But I’ve been getting enough reminders through comments and emails that I thought it’s time to tackle this challenging episode.
Yes, this is an episode with a lot of Physics and Mathematics. But you will observe it has a very gentle learning curve since there is enough background presented in the problem requirements and in previous episodes. The real challenge is in translating the math to code.
Computers are computing devices crunching numbers all the time. So you might think implementing math formulas should be straightforward. Unless you are a scientist or a mathematician, in which case, you would know the truth which is – it is not straightforward at all.
I remember before Doom came out, it was very hard to develop a 3D engine. Most of the available research involved understanding computer graphics text books with a lot of math theory. It’s a painful task to translate formulas into algorithms and later performant code. There are many ways you could get it wrong. But only one way to get it right. Even more frustrating is forgetting to account for edge conditions like a negative result or divide by zero and floating point errors.
I remember referring one of the most popular books at that time Numerical Recipes in C++ to understand how to implement some of the algorithms. But I had to abandon the project after a working prototype because making a game engine (alone) is a tonne of work!
In this part, I have used a lot of images and slides to make sure that I don’t skip any explanations (like how cosine and dot products are related). I know that these videos are being watched by all kinds people – students, experienced programmers and non-programmers. So I have not made any assumptions.
Hopefully you would enjoy this part without any challenges. Even if you do, it should be fun 😊
These are the topics we will cover in this episode:
- Adding lights
- Phong reflection model
- Ambient, Diffuse and Specular Shading
- Sub-problem: Let there be light
- Coding the solution
- New classes
- Command-line arguments with argparse
- Progress Bar(?)
Here is the video:
Code for part four is tagged on the Puray Github project
Books and articles that can help understand this part:
Game Engine Architecture Great introduction to graphics concepts and techniques used in computer games. It might be different from raytracing since focus is on realtime rendering rather than realism.
argparseis the new standard for Python argument parsing.
Note: References may contain affiliate links