Milestone 2 is out. I originally planned to add some camera controls, but ended up rewriting how cameras integrate with the scene graph entirely. Along the way I also built the foundations for the game object system, a bunch of ImGui debug widgets, and a small spaceship demo where you fly around with a gamepad.
Since wrapping up milestone_1 in October, I've been working on tooling and performance infrastructure. The focus has been on frame timing control and debugging capabilities - things you need before scaling up to more complex scenes.
I use GitHub Copilot mainly for Code Reviews. I think it's tremendously helpful when working on a solo project with a large codebase as it hints at typos and logic issues that easily slip under the radar when writing only coarse-grained tests for the sake of it. I also tried Claude and Gemini. All those tools are sometimes helpful, sometimes annoying.
What's been on my mind: when I accept code I haven't thought through myself - do I still understand what I'm actually building?
I've published an accompanying technical report on my game framework helios that outlines the key architectural decisions behind the prototype and discuss its further development.
As announced in a previous post, I've made progress on the rendering pipeline. The SceneGraph and RenderPass system are in place now, separating scene graph traversal from the actual rendering commands.
The first abstractions for the rendering model have found their way into helios, and the first example application has already rendered its first primitives onto the screen (aka the Hello World! of 3D Computer Graphics).
de Vries' book on OpenGL is proving (once again) to be very useful, as it provides some common, coarse-grained abstractions that serve as a great starting point for further refinement. Think of separating concerns like Meshes, Materials, and Shaders.
I feel that I've spent most of my recent time with refactoring, restructuring, and developing throwaway prototypes that get discarded every weekend - and that's a good thing. The time between development cycles is currently filled with the intense evaluation of algorithms in digital image processing and reading through Game Engine Architecture by Jason Gregory, which repeatedly provides me with new perspectives.
Continuing from my article on Model Matrix Rotations, I've written about projection matrices - one of the final steps before rasterization.
main() serves as a great example of yesterday's restructuring in practice: The OpenGLDevice is created, then passed to a GLFWApplication which manages window creation and the main loop. The ultimate goal is for the application to own and provide the input system, further simplifying the program's entry point and properly encapsulating platform-specific details within the appropriate module.
The last few days have seen some restructuring in the helios codebase, with namespaces and modules being reorganized. This was mainly driven by a clearer definition of responsibilities for individual classes, which can now be better refined as the implementation progresses.