M.I.C.R.O Solo Graphics Engine & Tool

M.I.C.R.O, short for My Input Controlled Real-Time Output, is a real-time rendering engine supporting physically based materials, image-based lighting, shadow mapping, and an HDR post-processing pipeline, built entirely from scratch in C++ and OpenGL. I first wrote it in 2024, purely as a technical exercise: could I understand and build the systems that power the engines I'd spent years using? That first version worked, but using it was rough. Models loaded at the wrong scale, textures broke, and the program gave no indication when something had gone wrong.

I came back to the project in 2025, once I'd started moving into product and interaction design, and treated it as a second problem. The engine already proved I could build the hard technical parts. What it needed was an interface, a flow, and a level of polish that could stand next to a shipped product.

This is a solo, self-directed project with no client and no external deadline. I started it during my undergraduate studies in game design and programming, out of curiosity about how the engines I'd used for years actually worked under the hood, not as a step toward building games professionally. The first build took about two months in 2024. I set it aside once the technical core worked, then returned to it roughly a year later, once I'd started transitioning into product and interaction design, and spent three to four weeks turning it from a working prototype into something with an actual interface and a stable, testable release.

The scope was deliberately narrow. This was never meant to compete with or replace an existing engine, and I never intended to support anything beyond Windows, the platform the overwhelming majority of anyone who might try it would actually be running.

The first version of M.I.C.R.O proved I could build a real rendering engine: PBR shading, shadows, image-based lighting, all working correctly. What it didn't prove was that I could design something. Models spawned at random scale and orientation depending on how the source file happened to be authored. Textures either failed to load or rendered scattered across the model. And if anything went wrong, the only feedback was whatever printed to a terminal window, which defeated the point of a program meant to feel like a finished, standalone product. A technically impressive engine that's confusing to use doesn't demonstrate design skill, it demonstrates the opposite.

I didn't run a structured study for this project. The reference points were informal: years of hands-on experience with existing game engines and 3D tools, plus attention to what other people said about the tools they used, what felt intuitive, what they complained about. The camera control scheme came directly out of that, a pattern shared closely across Unity and similar software that I'd personally found the most comfortable across years of using different programs.

The intended audience shaped the decisions too. M.I.C.R.O was never going to be someone's first piece of 3D software. Anyone likely to open it, a fellow developer, a student, someone browsing the repo, would probably already have some familiarity with how engines and viewport tools typically behave. That assumption is why I leaned on established convention instead of inventing a new interaction model from scratch.

The gap between the two phases matters. Everything under the hood, the renderer, the shaders, the model loading, was already working by the time the design pass started. That let the second phase focus entirely on the parts a user actually experiences: how a model gets in, what the camera feels like, what happens when something's wrong, and whether the whole thing survives running on a machine that isn't mine.

M.I.C.R.O now ships as a proper Windows installer, alongside a portable, no-install option, both distributing the full engine with its dependencies included. I tested the final build across a real spread of hardware: dedicated and integrated GPUs, Intel and AMD, a range of RAM configurations, and both Windows 10 and 11, first on my own machines and then with friends and family running it on theirs. The early product design phase broke on several of those combinations. The released version didn't.

This was never intended to be a widely used open source project, and it isn't one, there's no meaningful download or star count to report here. What it did become is what I set out to make: proof that I can take something technically solid and turn it into something someone could actually sit down and use, built entirely on my own.

Coming back to a project where the hard technical parts already existed let me focus entirely on the experience layer, which is exactly the muscle I was trying to build. Deciding to match an existing control scheme rather than invent my own was probably the single decision that taught me the most: familiarity can be a design choice in its own right, not a lack of one.

The gap, looking back, is that all of my testing was really quality assurance, does it run, does it stay stable, across different hardware, rather than usability testing with someone encountering the interface cold. Friends and family who tested it already had context on what the program was for. I don't have a clear picture of how someone with zero familiarity with 3D tools would actually experience it.