Brayden here. This week I'm going to talk a little about refining code.

Basically, what generally takes us the longest when working on the game is refining code. We add features every other week generally, and then spend the following tweaking and fixing everything we made the week before. That's why it's so hard to keep these blog posts frequent, is because we often only get to add new cool stuff worth mentioning every other week.

This week, I refined primarily the AI. I did work on the Input systems some more and did fixes all around the engine, and I'm quite proud of the result. The AI now works in a somewhat pack-like state, which is kind of interesting because I didn't intend this. For example, in what I'm calling the "warzone floor," which is the second floor of the game and part of the tutorial, I noticed that the rebels would fight off guardians and then move forward in a pack to help out there friends who were being pushed back above. Traveling with them and helping turn the tides of the short battle was pretty fun for me, because it felt like I was really part of a transgression.

Ricky has been doing his thing with the texturing, in fact, Novem's new textures are done. I just need Forrest to set up his rig with the new UV coordinates and it'll be in the game. These textures not only add detail, but also establish an artstyle we're going to start aiming for. The model itself received fixes from Ivan on the normals. Although, no screenshots just yet, we're saving the new artstyle for the upcoming 7th playable demo and video. 

Rafael is also working on his new tracks for the game to go with the tutorial, and he hooked us up with some new sound designers who are going to be doing some cool stuff soon as well. Which, by the way, Rafael did some concept tracks a while back for We Shall Wake, so if you're interested in hearing what it's going to be like, check it out!

Anyway, that's for today! Take care guys, have a great week.

Hey, guys.

This week saw a lot of progress, with much of my time spent on the new anti-aliasing technique that will be featured in Insomnia, but first I'd like to mention a few minor things.

SSAO has been improved even further to smooth out the normal of the surface being tested, so the intense shimmering and aliasing that occurred in some rare cases have been mostly eliminated. This had a minor performance hit, but the quality improvement allows me to cut back on other parts of SSAO, so performance remains the same.

The UI renderer got a complete rewrite and is now faster and better than ever. It turns out that some of the special effects that we applied to the UI did not result in any visible visual change. They also turned out to be surprisingly expensive on weak hardware (God damn it, Intel; you can't spend 4 of my precious 16 milliseconds on the user interface!) The revamp both makes these special effects look better AND allows them to be turned off as a desperate last resort to save some GPU power.

Other parts of the engine got some minor optimizations as well, but nothing near as significant as last week. For example, particle rendering performance was improved a little bit.

As a result of our optimization push, we've managed to optimize the game for low-end hardware to an almost ridiculous point. Insomnia used to run at under 10 FPS on a weak Intel GPU, but thanks to our optimization efforts, we're now getting almost 40 FPS on that same GPU, meaning that as long as the game starts (e.g. the GPU supports OpenGL 3.2), you should be able to tweak it to playable FPS.

With that out of the way, let's get down to what this post will mainly be about: Anti-aliasing! Be prepared that this is a pretty long text, so if you're not ready for a deep dive you may want to just skip to the middle where there are some screenshot links.

Anti-aliasing is almost always featured in games in some form. I suspect that if you find my blog posts interesting enough for you to read this far, you already know what anti-aliasing is and does, but for the sake of it I'd like to give a brief explanation of what anti-aliasing is.

Anti-aliasing techniques are techniques that attempt to minimize the aliasing in the scene. Aliasing occurs when there are details or movement that are less than a pixel in size. A 3D model is made out lots of mathematical triangles described by 3 points in 3D space. We project this 3D model to the screen and check which pixels that the triangle overlaps. However, we do not have an infinite number of pixels, so the result not entirely accurate. If a thin triangle happens to fall between the pixels, it'll completely disappear, and if a triangle moves less than a pixel, the pixels it covers may change in weird ways patterns that simply put looks unnatural and unpleasant, and our brains interpret these unnatural pattenrs as flickering, shimmering and even objects changing shape.

There are two approaches to anti-aliasing today. The first one is to simply generate and gather more information about the triangles. This is what the famous MSAA, also called multisampling, does. Usually the graphics card simply tests if a pixel's center lies inside the triangle to determine whether the pixel is covered or not, but to better describe the shape of the triangles we can test multiple points inside the pixel. For 4x MSAA, we get 4 times as much information to work with, so we can get much higher quality result.

The second one is the filtering approach. This involves looking at the information we already have and attempting to make the most out of it. FXAA, another famous anti-aliasing technique, falls into this category. FXAA attempts to analyze the final image and reduce the aliasing in it by detecting edges and smoothing them out. It's often called inferior to MSAA, and for good reasons. It's cannot restore triangles that never covered a single pixel center, as its limited to the information at hand.

Another filtering technique called Temporal Supersampling combines the current frame with the previous frame. This essentially grants us more information to work with for free, but introduces a lot of problems, like ghosting or blurry textures. Regardless, techniques that use the previous frame have been used in many successful commercial games, like Crysis 2. It's also used in Nvidia's new anti-aliasing technique, MFAA, but I digress.

Up until now, Insomnia has only supported FXAA, and for good reasons. FXAA may have low quality, but it's cheap and extremely easy to implement for any engine. MSAA on the other hand is quite the opposite. MSAA requires modifying approximately 60% of the graphics engine to implement. This is not something that your average indie developer can afford the time to do. We'd essentially be having TWO engines to maintain at that point, which means adding more features becomes even more time consuming. In addition, MSAA has problems when working with high-contrast edges, effectively causing bright edges to bleed over less brighter edges, which reintroduces aliasing again! These are the reason why Insomnia doesn't, and won't, support MSAA.

I believe that the answer lies in hybrid solutions that both generate additional data and do proper filtering of it. Therefore, Insomnia features a new anti-aliasing technique developed by yours truly which combines all three of the above described techniques. I call it TSRAA, Temporal Subpixel Reconstruction Anti-Aliasing, and as of now it is officially part of the Insomnia source code.


Note: Still images are not enough to fully appreciate the benefits of TSRAA. What's REALLY going to blow your mind is how smooth it looks in motion.

What TSRAA builds on is that these three techniques compliment each other very well. Thanks to this, the quality of 4xTSRAA in almost all cases is higher than that of 4xMSAA, and in the rare case where there is clashing information in a pixel the quality drops to ghosting-free temporal supersampling only (which also could be argued to provide higher quality than 4xMSAA as well). TSRAA also implements a counter-measure for high-contrast edges (also an innovation from me =p), ensuring smooth gradients at all times. Here's a comparison!

Performance and memory usage are both excellent. Working with the data you already have is always fast, and the extra data we do generate is both cheap to generate and requires little memory. 4xTSRAA has around half the performance impact and memory usage of 4xMSAA. Even 8xTSRAA is faster and uses less memory than 4xMSAA, and less than 1/3rd of the memory used by (shiver) 8xMSAA.

Finally, TSRAA was a lot less complex to integrate into our existing engine. While MSAA essentially requires complete rewrites of large parts of the engine, TSRAA integrates and builds on top of our existing code in a much cleaner way.

So there you have it! Congratulations for making it this far! I know that this got a bit long, but I'm a bit of an anti-aliasing fanatic, and it's really exciting for me to actually get the chance to come up with and even implement all this. This is the culmination of over two months of work! Thank you for your time!

[04:42:25] Mokyu (TheAgentD): Can I write "buttload" on the blog?
[04:42:29] Mokyu (TheAgentD): Will you get mad at me?
[04:42:44] Brayden: no lol
[04:42:46] Brayden: why would I?
[04:42:51] Mokyu (TheAgentD): BUTTLOAD IT IS
[04:42:52] Brayden: Also why did you put buttload in quotes
[04:43:01] Brayden: I'm sitting here giggling like an idiot lol