After Vulkan based investigations I made few years ago, I started right away in my self-driven-like-a-lost-fish-in-the-ocean heavy experimentations in order to prepare the path for myself to start in creating a Vulkan (only) based engine. Till this moment I’ve built several 3d apps/engines, two crappy ones (one crapy & one crashy!), and the current one which is in progress and (hopefully) will be the best of the worst! The first two iterations contained a ton of branches at the repository, enough to confuse me, not to mention the thousands of lines commented either because it is not working, or because I was testing with. And crashes all the time for no safety or assertion check!

I learned a lot since that post, especially because I was officially super far far away from graphics coding for near a decade (fixing Unreal bugs or writing shaders not really something to count -_-). Glad to say, a TON of lessons learned from trial & error and happy to say no hardware loss yet =D. But the most important lesson was the must of getting as far away as possible from using short cuts combinations, as I always either forget them, or re-assign several tasks to the same short cut, and sometime it get worst (keep reading about that unique case). And try more to invest in a better solution. Today’s issue that I want to highlight as part of the short cuts, is the debugging, view-modes & visualizations.

Since I started at the first engine iteration, NSight and Renderdock have always been my lovely friends, can’t deny the great help i got from them, not only to detect issues, but also to learn more about the new API. But at the same time can’t ignore the time get wasted sometimes to visualize or dig deep into something related to my passes or shaders. Not to mention that I was assigning the debug views into the numeric keys in my keyboard next to tilde’~’ (0-9) but as soon as I exceed that number, it started to be messy and a big as hell issue from all aspects!

Coming for a huge Unreal Engine based background, I must get some inspiration, I’ve always admired the tools in there, the ideas and the quality is top notch, so I decided to learn from that good user experience, and try to do a similar thing.

I loved this endless list of Unreal Engine viemodes and visualizers, and I found it will be a good milestone for my engine, in order to make it more usable and user friendly, even if it is not something that will be used by millions of users, but still, making it great is a priority in order to push my productivity and experience. So,…I started working on it!

After I finished adding similar solution, and I became very satisfied about it, and freed the memory allocated in my brain to remember near 20 use of keys and combinations. I came to the two major question I always like to ask:

• How to make my implementation different from the inspiration source “Unreal Engine”?
• How to make it better than any other engine exist?

I run away to check how Unity implemented this user experience, at the end of the day, Unity3d & Unreal Engine is the most common and diverse with features free and accessible engines out there. Unfortunately found it handled through the post-processing stack profile new thing. Which makes it much less usable than Unreal Engine, and makes it far away from my goals.. Making it better. But I appreciate the ability to edit parms foreach mode! Which became an inspiration for something else (will discuss in another post).

This led me to a bit of confusion, but that was good phase, and now I’m really happy to be confused. Because this confusion made me decided to add one more essential question to ask myself, which should help me in defining the how of making the inspiration better. The question was “Why I want it to be better than Unreal Engine ones?” ! The How doesn’t matter, or in another meaning, the How will be easily defined by the Why.

While I used to use Unreal 3 and now 4 for almost a decade, and have always been happy user and satisfied with those type of tools in there, asking myself the “Why” question helped me to see what been a hidden element in my user experience, and putting my hands on the reason that could led to decreasing my usability sometimes. That hidden element was the ability to compare between different views or buffers at the same frame in a decent way. I know Unreal have the “Overview” thing, but this show several buffers, far from each-other and even worst, in tiny squares.

For me, most of the time I was flipping between different views to check for whatever i look for. When I had those modes linked to the keyboard buttons in my code, I was able to toggle quickly between any two different viewmodes or buffers, and check whatever I’m seeking. So, my issue in the mapped keys was the hilarious numbers of shortcuts I need to remember, but my blessing with the mapped keys was the ability to compare in an efficient way. Voilà !

And that was the outcome of this personal brainstorming. To make it better, I need to fulfill the need of being able to easily compare the modes/buffers.

As soon as I switch to anything, but the final lit mode, a tiny lil slider will show up, to allow me in doing the “Split Visualization” of the modes. Not only that, but also I can compare two different materials/shaders assigned to the same mode (you can see cell shaded material in the video below for example). Later I’ll blog more about my implementation for the viewmodes, as there are some nice stuff going on under the hood, and some optimization tricks I made in order to not fall again into the issues or crashes I got at the first iteration. Not to mention some Vulkan tricks been learned the hard way.

Last time I blogged about Vulkan I said I’m 50/50 sure about it. But after ~couple of years by now since I started with VK, and more than what I ever wrote of lines been written in those crappy engines, I’m glad to say I’m 99% sure about it. And no\ way back to OGL! I’ll try to blog frequently about Mirage engine, and if all goes smooth to the end of my plan, I might put the entire Mirage source online. Not sure yet!

And of course, the model is Emily.

-m