Offline to Realtime: the beginning of a journey

I feel I am far from home right now. For the longest time I cut my teeth on movies. Doing lighting, writing tools, writing rendering tech. It grew up very familiar, that type of familiar where instinctively you don’t need to make a plan to figure out what need to be done. That type of familiar where if you make a plan is because you need other people involved, and you need to express what’s in your head.

It’s different now. I work at NVIDIA on real-time raytracing. The future of rendering, right? But even though the concepts are the same, the techniques and methodology to deliver something are completely different! Enter, graphics APIs.

So far, I have been playing in a niche world where you write your own software, you play by your own rules. Don’t like the world those rules manifest? Change the rules! You are the master of your digital world, an architect not bound by gravity and the compressive strength of construction materials. Basically, if you can conceive it, you can make it.

Realtime graphics is different. You play by the API rules, if you are clever, you can bend them, but you are still bound by them in what you can do and cannot do. It can be a shock entering this world. Picture this: real-time graphics is the flying world made of open sky, thunderstorm clouds, and magnificent flying creatures. The offline rendering world is the marine world. Deep abyss, unexplored tranches, bizarre creatures thriving under enormous pressure. I am a deep-sea creature, who is flying now. I know how to take the pressure, but I have no idea how to fly straight!

It can be challenging to learn when you are part of a large team working on a complex project. Keywords: large and complex. Although you have many experts around that can tell you anything that there is to know, the project you work on is very complex and it is a real struggle to cut through the infrastructure, the abstractions and see the fundamentals concepts you need to master. I don’t have a good analogy for it. I need to start from scratch on a pet project where I draw a triangle.

I am a big proponent of “write your own libraries”. I also want to be practical and get to the learning phase quickly, without having to master platform-specific boilerplate configuration that I am nowhere near ready to appreciate. So not to waste anybody’s time I start from GLFW.

GLFW is a slim multi-platform library to create OpenGL-based applications (also supporting Vulkan). It gives abstraction layer to configure and spin up a graphic context where you are ready to draw and make something cool. It gives you easy access to user input devices, and all that you need to begin. The getting started guide tells you most of what you need to know, so you can be up and running in minutes (well, at least if you are familiar with CMake) In case you want to follow along and have no idea where to start, give that a go.

So, it begins… well, it “began”… a couple of months ago. Here is my very second test. After seeing the example compiled and I had a triangle, the first thing was to make it my own and change the geometry to something colorful and a little happier.

It is a humble new beginning. I don’t have any particular idea in mind, and certainly I won’t have much to teach to you, who are reading this and most likely know 10 folds more about real-time graphics than I do. But at least I hope we can keep each other company in my journey. Hopefully, at some point I am going to find myself at ease with graphics APIs and programming models, which I am not going to hide: right now it is something I find incredibly restrictive! Maybe one day I’ll be that sky creature that can fly straight, with deep-sea monsters stories to tell.

If people like it, I’ll write more short posts like this. As I get into something that is worth sharing, I’ll post some code and get into technical details and explanation. As I mentioned early, I have already done a couple of months of exploration and I need to catch up to that in this blog.