From Vertex to MeshData to device-specific Meshes - over the weekend, I took a sidestep from the math lib to focus on the architectural planning and development of the underlying rendering layer, accompanied by the scene layer that is responsible for abstracting scene graphs away from the actual rendering process.
helios now implements core vector operations, including subtraction for directional calculations, dot product for scalar projections, and cross product for normal vector computation and creating orthonormal bases, respectively. The cross product implementation utilizes constexpr specifications for compile-time evaluation when operands are constant expressions.
The lookAt function constructs view matrices for camera-space transformations following standard computer graphics methodology. The implementation creates an orthonormal basis from eye, target, and up vectors, then formulates the change-of-basis matrix with integrated translation components for camera positioning to the origin.
As a follow-up to my article on Model Matrices, which describes the connection to change-of-coordinates matrices, I've found the time to revisit the topic. I've written a new article about matrix composition in the context of the Model and Rotation matrices to highlight the algebraic foundations.
This weekend's development on the helios engine centered on finalizing transformation logic within helios.math.
The transformation functions translate, rotate, scale were implemented within helios.math.transform. A key decision was to standardize on post-multiplication (M' = M * T) for all transformations, to provide parity with glm: This convention ensures that new transformations are applied in the local space of a model matrix M.
As I was working on porting the rotation matrices for the helios.math.transform library, I took a detour to formalize the underlying linear algebra. My goal was to move beyond treating the rotational part of the model matrix as just a black box and instead understand it from a coordinate system perspective.
Over the weekend, I focused on refactoring mat4 and vec3. Additionally, I've made some adjustments to my toolset.
For a game engine, the first step isn’t rendering a scene or simulating complex physics - it’s laying the foundational bricks. This weekend, I eased dove headfirst into that foundation for my personal C++ engine project, Helios, and it was a fantastic journey through the nuances of modern C++ design.
My background is in the web world - I've spent years wrangling Java, JavaScript (and countless frameworks based on it), PHP (from Zend to Laravel over Symfony and self-written solution), and the closest I ever got to the metal was writing C, of which I thought it would give me a head start for a game engine project. In a way, it did: I wasn't scared of pointers. But it also gave me a false sense of security.
Hi everyone!
For years, my world has been one of software architecture and senior-level development, mainly focusing on integration of frontend systems into large scale web applications. I’ve designed systems, worked with teams of various sizes, and treated software development as a true craft. But sometimes, a single problem can change your entire perspective. For me, that was Day 15 of Advent of Code in 2024.