Reccy’s Ray Tracer 0.1.0 is out!

Last year I started working through the Ray Tracer Challenge by Jamis Buck, and I wrote a software ray tracer in C++. This was a highly educational and interesting project for myself as it gave me the opportunity to really learn 3D Maths and C++ in a fairly controlled way by working through the unit tests presented in the book. I finished that about a year ago, but I always wanted to add an editor or some tool on top of it that allowed someone to actually create their own 3D scenes without editing the source code.

Today I’m happy to say that I’ve finished my first editor implementation! I’ve been working on it on and off for the past few months and it was quite an experience, learning the basics of OpenGL, Dear ImGui and putting everything together.

The first version of the editor. Simple scene and material editor with a scene outline and inspector.
Render of the scene shown in the editor.

The first version of the editor can:

  • Save and Load Scenes to a .rrt file (XML)
  • Create, Edit and Assign Materials to different scene objects
  • Transform, rotate and scale controls for objects
  • Change render camera position and direction, and render dimensions

This is only the first version of the editor, as it doesn’t expose the full functionality of the core ray tracer. Features such as Constructive Solid Geometry and Pattern Materials aren’t implemented, but I might do so in the future. Realistically it’ll be bug fixes, small updates and refactoring the 3000 lines of code in the main class.

While that’s a small amount of features for v1, here’s a list of the low level systems that had to be implemented to support the user-facing features:

  • Replacing CMake with Visual Studio Solutions (I was spending too much time fixing CMake issues)
  • Cursor picking (Scene raycasting and collision detection, 90% of it was done for core raytracer)
  • Scene rendering (Setting up OpenGL VAO, VBO, Shaders, etc)
  • User Interface (Setting up Dear ImGui and all the minutia involved)
  • Gizmo handles – Transform, Rotate and Scale (3D modelling, implementing Torus collider)
  • PLY Model loading – Used Stanford PLY as it’s a simple format that supports vertex colors
  • The Math library (Never ever ever making my own Math library again, it’s just painful)
  • Model View Projection Matrix for Camera rendering
  • Probably a lot more I can’t remember…

Point is, there’s a lot of implementation details that’s easy to gloss over for what does seem like a simple project on the surface. Once I come back to this project in a future, I do plan on adding support for CSG and Pattern Materials. But, that’s quite a while away. I want to focus more on game dev in the near future.

Feel free to check out the source code and download the release! It’s completely open source so feel free to do whatever you want with it. The source code is available here: https://github.com/Reccy/CppRayTracerChallenge

You can also download the Windows release here: https://github.com/Reccy/CppRayTracerChallenge/releases/tag/v0.1.0

BONUS: Development Gifs

This was taken while trying to implement the rotation gizmo. It works fine now, but debugging rotation bugs is incredibly frustrating.
This is an early gif from when I first got the flycam and orientation gizmo working. The gizmo is rendered by the camera to an OpenGL texture, which is then rendered one frame later onto the screen.
Another rotation bug. Instead of storing the X Y Z euler coordinates separately, each scene object only has a quaternion rotation. Each frame the euler rotation is generated to display on the UI, then it is transformed back into the quaternion. This is clearly very unstable because of floating point imprecision and the fact that a quaternion maps to multiple euler angles. So now, the quaternion is generated from the euler angles.
Same bug as above.
No bugs this time, just showing off the working gizmos. The gizmos took a surprising amount of time to get implemented.