The Concept:

I recently started learning OpenGL, and I’ve been exploring it for about four months now. Along the way, I’ve had the support of several companions who have helped me navigate the challenges, people who have shown me the path, and I’ve also relied heavily on the excellent resource, learnopengl.com.

Many people, including myself, have begun their OpenGL journey through this amazing website. This post is my small ode to its author, whose work has guided countless learners.

I’ve always been drawn to visual and graphical outputs, so I feel graphics programming is the perfect field for me. What excites me the most is that it allows us to create, simulate, and visualize complex concepts—whether it’s engineering problems, physics systems, or even advanced topics like fluid simulations.

The Tools:

At the core of these graphical APIs lies a fascinating branch of mathematics that most of us encounter in high school: Linear Algebra. It allows us to represent everything as vectors, providing a powerful way to describe and manipulate space. These vectors form the building blocks for transformations, rendering, and the simulations that bring computer graphics to life.A Vector is mathematically represented as :

$$\vec{v} = x\hat{i} + y\hat{j} + z\hat{k} \quad \text{or} \quad \vec{v} = \begin{bmatrix} x \\ y \\ z \end{bmatrix}$$

The first form expresses the vector in terms of unit vectors, while the second form is its general mathematical column representation.

But vectors alone aren’t enough—we also need a way to transform them. That’s where matrices come in. A matrix is essentially a compact set of numbers that tells us how to scale, rotate, move, or project vectors into different spaces. In computer graphics, almost every visible action—moving a model, rotating a camera, projecting 3D onto a 2D screen—is achieved by multiplying vectors with matrices.

Together, vectors and matrices form the “language” of graphics programming: vectors describe objects, and matrices tell them how to move, rotate, or reshape in the virtual world.

The Creation

Much like traditional CAD software, this editor allows me to create and manipulate 3D objects in a scene. Over the past few weeks, I’ve been steadily adding features that make it feel like a real editor—something that goes beyond a simple OpenGL demo:

• Basic Shapes: The ability to create primitives like cubes, spheres, and cuboids.

• Transformations: Move, rotate, and scale objects interactively using the mouse and keyboard.

• Camera Controls: An orbital camera to navigate the 3D world, making it easier to explore scenes.

• Lighting & Shading: Simple shaders that add realism by simulating light sources.

At first glance, these features might sound ordinary, almost expected. But to me, each one carried a hidden challenge:

• Building shapes wasn’t just about drawing; it meant learning how vertex buffers work and how geometry actually flows into the GPU.

• Implementing transformations forced me to get comfortable with matrices—not just theoretically, but as practical tools I had to use frame by frame.

  The camera system became an exercise in input handling —how to translate mouse movement into smooth navigation.

• Writing shaders was like unlocking a new language. Suddenly, I was programming the GPU directly, discovering how even a few lines of GLSL could drastically change the look and feel of the world.

Over time, my project grew beyond a simple C++ project and developed into a complete editor—something I treated as an actual project, where I could test ideas, refine concepts, and see abstract math applied in practice. The more I learned from the LearnOpenGL online reference the more features I was able to add, and the more creative I became with experimenting and extending the editor and I’ve got to admit - “It was a fun experience..”

Every bug became a lesson. Every crash was a reminder of how unforgiving graphics programming can be—but also how rewarding it is when things finally click..

By now you might be asking: “Okay, this sounds cool, but what makes your editor stand out? After all, many people build small OpenGL projects—what makes yours different?”

That’s where my special feature comes in.

Unlike most basic OpenGL editors, mine has the ability to be scripted directly with Python. Instead of hardcoding everything in C++, I can now write Python functions that interact with the editor, control objects, and extend its functionality—all without recompiling the program.

In other words, this editor isn’t just about creating shapes—it is where C++ performance meets Python flexibility.

Along the way, I wasn’t working in isolation. I had guidance—one of the most valuable insights came from my dad, who introduced me to SWIG (Simplified Wrapper and Interface Generator). He had come across it while exploring FreeCAD’s codebase, and that single pointer completely changed the entire course of my project.

With SWIG, I was able to bridge C++ and Python. At first, the idea seemed overwhelming—“wrap C++ classes and call them directly from Python?”—but once I grasped how it worked, it unlocked an entirely new dimension for my editor. Suddenly, I could combine the raw speed of C++ with the scripting freedom of Python, without ever recompiling the core engine.

The process went like this:

• I defined my C++ classes (like Cuboid, Sphere, etc.) normally.

• Then I wrote SWIG interface files (.i) that told SWIG which classes and functions to expose.

• SWIG then generated the necessary Python bindings, which I could import as regular Python modules.

This meant that if I had something like:

Cuboid c(1.0f, 2.0f, 3.0f);
c.Draw();

in C++, I could now do the exact same thing in Python with:

from Shapes import Cuboid

c = Cuboid(1.0, 2.0, 3.0)
c.Draw()

And here's the most exciting part: the Python-created objects seamlessly integrate into my C++ editor's OpenGL context. This means that when you write Cuboid(...) in Python, it actually generates a real 3D cuboid within the editor's scene.In order words, it was real time!!

This was a transformative feature. Suddenly, my editor became scriptable, allowing me to write high-level automation, generate procedural geometry, and test new features—all using Python—without modifying the C++ core.

While it might seem trivial to some, this scripting capability required a significant amount of backend coding in my project.

Conclusion:

Looking back, what started as a small experiment to learn OpenGL has turned into something much more meaningful—a real editor that combines the raw performance of C++ with the flexibility of Python scripting. Along the way, I’ve discovered how mathematics, code, and creativity converge in graphics programming.

But this is just the beginning. There’s still so much to learn: advanced rendering techniques, physics engines, GPU optimizations, and maybe even exploring Vulkan or real-time ray tracing. Each of these areas opens up endless possibilities for where I can take this editor next.

More importantly, I’ve realized that graphics programming isn’t just about building software—it’s about building a mindset. It teaches patience, problem-solving, and the joy of turning abstract equations into something you can see, move, and interact with.

A Note of Gratitude

None of this would’ve been possible without the people and resources that supported me: the community of graphics programmers sharing knowledge, the author of learnopengl.com, and especially my dad, whose one suggestion about SWIG opened the door to making my project truly unique.

Final Thoughts

In the end, this editor is more than just a project—it’s a playground. A space where I can learn, test ideas, fail, fix, and create. It’s proof that with curiosity, persistence, and the right tools, anyone can take a simple interest in computer graphics and turn it into something tangible.

And for me, this is just the start of a much bigger journey into the world of graphics programming.

Hope you guys liked it, stay tuned !!!