Hello everyone.

My last exams are over at last (who the hell put them AFTER Christmas?!) and although I was able to work a bit on the WSW and Insomnia during this time, I've neglected this blog a bit. For the half dozen people who actually read this, I can happily announce that regular Wednesday updates will resume from now on.

I think everyone's noticed the new grass effect we have in the new trailer/combat demo. Rendering dense grass with a decent render distance is really hard. In our case, we decided to go all out and allocate a large amount of our GPU time budget for grass rendering. The idea is that for the outdoor scenes, we will not have a significant number of lights, allowing us to shift part of our lighting budget to grass rendering. In addition, since grass is a purely aesthetic effect, it is easy to tweak and even turn off completely in case your computer simply doesn't like drawing a few million straws of grass each frame...

More recently, the grass renderer was updated with support for TSRAA, Insomnia's novel anti-aliasing technique! This relatively cheap anti-aliasing method had a massive impact on the grass when enabled. And to think that to this day, there are a lot of engines that haven't even gotten decent anti-aliasing at all implemented...

Anyway, here's how it looks without TSRAA.

Aaaand with TSRAA.

The difference should be obvious. As always, I can say that it looks even more impressive under motion, especially subtle motion like when it sways in the wind, something FXAA or SMAA cannot deal with at all.

Finally, particle motion blur finally got the rewrite it deserved. It's be both faster and more accurate now. Even the code is simpler and cleaner. =P

Rant on spaghetti code

The most important thing when you're a programmer in a team working on a bigger project is to keep the code clean. What does "clean" mean? Apart from the obvious (good variable names, not letting methods and files get too big, add comments for complicated code, etc), the most important thing is to have as few dependencies between different parts of the code as possible. Essentially, we want the graphics engine to work like a magic black box. Brayden tells my code what to draw and where, and my code should get the work done. This means the magic box needs a number of controls, levers, buttons and displays so he can use it. These controls should be as simple as possible, yet flexible enough so that he can do what he wants with it. Brayden shouldn't need to, no, he shouldn't be ABLE to unscrew the lid of the box and jam his hand into it because he wants some piece of information or wants to do something the controls want let him do.

Why is this important? Maintainability. From Brayden's perspective, the graphics engine is a huge black box, but inside it there are a number of smaller black boxes wired together. There's a box labeled "Model Renderer", another one labeled "Particle Renderer", one named "Grass Renderer", etc. These are all connected to the main "graphics engine" controls in extremely specific and well-defined ways. This means that when Brayden pushes buttons on the graphics engine, they get translated to button-presses of the boxes inside it; button presses that the engine knows will work with the internal boxes. In the same sense, Brayden places my graphics engine box right next to his Combat and AI boxes, and wires them up as he sees fit.

Having strict rules on what code is allowed to access what code is extremely important. An hierarchical approach like this, where one part of the code knows (and cares) as little as possible about what other parts of the code does, is much easier to maintain, modify and expand. If the grass renderer suddenly had to be wired up to the model renderer, and the model renderer had to be wired up to the transparency handler and everything had to be wired up to everything else, we get a huge problem. Suddenly the boxes are no longer independent of each other, and modifying one may break another one. We end up with an extremely complex web of dependencies instead of a simple hierarchy, which means that over time adding features gets more and more complex and time-consuming. This is what's commonly called "spaghetti code". With the hierarchical approach, the rules we've set up limit the number of places that can be affected by a change, making the engine much more structured in the end. The point is that each box should be as simple as possible, and interact with as few other boxes as possible.

These last few weeks, I have spent a decent chunk of my time working upgrading controls and adding new controls to the graphics engine magic box. When Brayden wants some new piece of information or a control of some sort, I delve into the internals of the box and draw a new wire from a control to the module that holds that information or handles that part of the engine. Once I get too many free-running wires in the box, I bundle them up and create a new box which I task with managing that control, and that's how a new box is born! It's actually quite fun!