Prototyping the Rendering Pipeline​

As announced in a previous post, the past weeks were used to make significant progress in refining the architecture of the rendering pipeline. One of the key updates introduces the SceneGraph and the creation of RenderPass objects derived from the (culled) scene. The new architecture aims to enhance the explicit management of rendering commands, ensuring a clearer separation of concerns between scene graph traversal and the final graphics API calls.

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.

The endless tale of yet-another-framework​

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.

As a follow-up to my article on Model Matrix Rotations, I'm continuing my exploration of the OpenGL rendering pipeline's mathematical foundations. This new article examines projection matrices, one of the final computational steps before rasterization transforms 3D geometry into the 2D pixels we see on screen.

In the spirit of yesterday's refactoring efforts...​

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.

Subsystems, subsystems, subsystems!​

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.

This time, there will be no Feature Creep - I promise!​

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.

Updates from the commit log​

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.