Vision

Vision. I often heard this term, read about it, though I knew what this is. I thought, when there is a person in charge, who is a highly skilled engineer, he can see what others can not just because of his engineering capabilities and the fact he goes thinking deeply about the problems (not only existing ones, he is also in a constant search for the new ones). Apparently, it's not that simple.

It turned out, vision is not a consequence of engineering skills but something very different. It's an extraordinary ability to see the future, a hypothetical future of a product evolution. By seeing this, a revisionary can drive product development in leaps, thus making it a revolutionary progression.

It is important to realize this is not "just" about development time (or, the availability of shortcuts). Evaluation is all around us. We evaluate everything we are doing in order to learn from it and adapt. Others evaluate our work in order to figure out if they want to invest in it. Thus, being able to leap forward gives you an instant advantage in terms of evaluation outcome, which transforms the benefit of having a vision from quantity (of time) to quality.

I faced the vision problem when tried to design a large system, in collaboration within a team. I realized (for the first time) that it's not the engineering skills that we lack, but rather a clear vision over where we are going. It doesn't even matter if you are an architect, lead developer, or the god himself. If you got the vision, you'll be heard.

Aside from being mysterious, vision is still a human skill. I wonder if it can be trained, like any other human skill we have. What kind of activity would that be? I don't believe that by just thinking and brainstorming we get any better in visioning in general, we merely dig harder at a specific problem instead. There must be something more generic. Perhaps, playing the music?..

What I know about Computer Graphics

I've been working closely with CG both professionally and as a hobby for the past 5-6 years. I've been making games and developing engine architectures. Latest developments can be tracked on Claymore Dev blog. I've seen different techniques, tried many others, even written articles about them in big books (GpuPro-3, OpenGL Insights). And the funny point is: I still don't know how to build engines... All I know is how bunch of known techniques may help or screw you up, based on personal experience.

Uber-shaders
Problems: Difficult to maintain due to bad granularity and monolithic approach. Unable to extend from the game side.
Alternative: Shader compositing. In OpenGL you can extend the functionality by either linking with different shader objects, swapping the subroutines, or by directly modifying the source code.

Deferred shading
Problems: Very limited BRDF support. High fill-rate and GPU memory bandwidth load. Difficult to properly support MSAA.
Alternative: Tiled lighting. You can work around the DX11 hardware requirements by separating lights into layers (to be described).

Matrices
Problems: Difficult to decompose into position/rotation/scale. Take at least 3 vectors to pass to GPU. Obligation to support non-uniform scale (e.g. no longer skipping invert-transpose on a 3x3 matrix to get a normal matrix).
Alternative: Quaternions and dual-quaternions. Both take 2 vectors to pass.

Context states
Problems: Bug-hunting is difficult because of bad problem locality. Assumptions over the context are easy to make, but if you decide to check it with assertions, why not just pass the whole state instead?
Alternative: Provide the whole state with each draw call. Let the caching work for you.

C++
Problems: Memory management and safety. Compiler-generated copy operators/constructors. Pain dealing with headers and optimizing the compile time. Many many lines of code.
Alternative: Rust. Other "safe" languages (.Net family, Java, Python) are not as low-level and often trade performance for safety (i.e. global GC phase causes an unacceptable frame rate interruption).

All I actually know is that there is a thousand and one difficult architectural issues of the graphics engine, and there is no silver bullet to most of them. For the most common solutions I listed possible alternatives, but they are no near being flawless. I hope that one day the amount of experience I get will magically transfer into the quality of my decisions, and I will finally know the right answers.

Rust

Today's early morning I woke up with a single thought reflecting loudly in my brain: "Dart was a mistake, it was not made for me. I should look for some statically typed practical language instead". Even though my KriWeb project (written in Dart) was not actively developed, I agreed (with my dreaming counterpart) that the instrument I choose for this project iteration is far from perfect. Suddenly, I felt the urge to look for something ideal, something that seemed so real as if I was reading its specification the other day... And I just needed to recall its name...

I started looking for it on the web. There were many interesting suspects among new languages. Ceylon, for example, features immutability by default (which highly encourages functional style), which seemed very familiar and close to what I looked for. It is a very nice language all in all, but it's currently running on Java VM, and was heavily inspired by it, what pushed me off. Go sounded attractive due to the strong support from Google, however disappointed me by its lack of user generics. Zimbu looked too original, while Haxe seemed to pretend covering too much use-cases. I've reached  the 5-th page in google search results, and there still wasn't any trace of it. Maybe it was a dream?..

One step away from stopping my search, I stumbled upon this Holy Grail of programming. Name is Rust, developed by Mozilla Foundation. Suddenly, I remembered this shining website interface, this clear language specification that I read a while ago. I found it, at last! Let me explain why I was so happy:

• Strong static typing with inference, only explicit mutability. This is so right and so rare to see at the same time. Unlike Dart, most of my mistakes will be found at compile time.
• No page faults while still compiling to native code. Memory model is protected and guaranteed to work without access violations under normal circumstances. It has a potential for C-like performance, hence being a better tool for various tasks.
• User generics with constraints, pattern matching (Haskell-style). Yes, it took the best from my beloved purely functional language.
• Less statements but more expressions and closures. This makes it even more sleek and functional.
• Syntax extensions. Hello, Boo macros!
• Structure compatibility with C. Using external API's (i.e. OpenGL) gets easier.

Overall, the language and its environment seem very nice. It is simple yet powerful, and feels very promising. I'm looking forward to work closely with this gem, and I'm very excited :)