Katana’s Material System

I think about mid 2012, I was realizing we had a number of duplicate textures we were using. I thought an appropriate solution was to add a form of scripts that could redirect the loader to a pre-existing texture instead, to save us from having hundreds of duplicates. This was just a side idea of mine but I thought it would make things much more efficient, especially when defining multiple skins for models.

This is often how most additions to the engine come about, first I look for a problem and then figure out a solution; the implementation is often when things get expanded out depending on how difficult the implementation turns out to be. To my surprise, this was relatively easy, so the system got spanned out quite drastically compared to what I originally had in mind.

For starters, I didn’t want to copy an existing implementation, such as Quake 3’s materials (or “shaders” as they’re called) because, by general rule of the thumb with Katana, is that I try to implement everything myself in the hope that I can utilize it better for our own uses, but also not be constrained or limited by already existing implementations.

It actually wasn’t until last year, 2014, that I finally got round to implementing it and it turned out surprisingly easier than I thought. Or rather, the initial implementation did! One of the things I spent a lot of time thinking about, was the syntax. Initially I decided to try doing my own thing; first the initial section which was filled with sub-sections that represented each skin.

The ordering of this was completely handled by the rendering pipeline and you had no control over the individual properties of each texture added to the material. There were no flags or other information you could utilise. It was rubbish, but for a while it did the job pretty well. That all said however, I quickly learnt that this was hard to understand, in some sense, and not quite as expandable in the long-term as I desired. I ended up throwing out the implementation in the end and rewrote it in, what I hope, is a smarter and more expandable manner. The new syntax introduced a number of new features.

      • Contextual functions that function differently depending on where they are used within the script.
      • Complete control over each texture layer of the skin and their order.
      • Support for texture rotating and scrolling.
      • Control over different texture blending modes.
      • Alpha-overriding.
      • Flags for skins, textures or globally.
      • Global flags for alpha-testing, blending and preservation.
      • Access to internal textures.
      • Global material names.

The only problem afterwards was updating all our materials. Luckily though, Maik, Decay’s level designer, quickly produced a small application which would recursively go through the directories in the materials folder and produce materials with the updated syntax; sorted!

Unlike my initial implementation however, there was a lot that had to be overhauled to achieve it. For starters, the engine was expanded to support additional layers for multi-sampling which weren’t necessarily in an expected order, since the scripts now had complete control over it (support for multi-texturing was also made a requirement). As a solution for this, a tracking system was introduced, that’s dynamically allocated on startup depending on the number of supported multi-sample layers, which keeps an eye on what TMUs are active, what texture is assigned to them and the current blending modes.

The actual rendering of the material itself however, is hardly elegant and there’s lots of room for improvement. Essentially, there’s both a pre-pass and post-pass for materials which is done when drawing an object, this iterates through each texture within the currently active skin of the material and ensures that each TMU is set up appropriately. Currently the second TMU is always reserved for the lightmap, though this is just a leftover from the original implementation and will very likely change, only remaining for cases where no lightmap slot is declared within a material. Detail texturing is currently done by just multiplying the original UV coordinates by a customisable console variable, which I would like to change in the future so it’s not reliant on the current UV map of the object. Generally, as well, for any UV manipulation we can end up iterating through object vertex lists multiple times which really needs to be improved.

In addition, as I’m sure some people know already, I also developed a WYSIWYG editor for materials which the engine integrates into. The editor is a powerful tool, because it not only renders materials as they would appear in your game, but your changes can be reloaded on the fly so that there’s no reason to manually load up your material again, meaning there’s quick iteration and instant feedback.

There’s a few things I want to explore in the future and expand upon, such as being able to declare variables within the scripts. I’ve also thought about materials as binary files that would exist alongside the scripts, the material would automatically generate the binary files if one doesn’t exist and load it instead. Additionally I would like to implement my own texture format that could contain information necessary for particular textures, for example how they would be rendered in the world, how many mipmaps they might support and other information like that (very similar to Valve’s VTF format, for those familiar with it).

Thanks for reading!


I have a personal issue with Unity, Unreal Engine 4 and some other video game development platforms out there; templates. Why? Well let’s find out!

Many moons ago, back in the days of Quake, Half-Life and Unreal, people were developing modifications that could have easily been standalone titles. These modifications were, more often than not, developed on top of already existing code, that’s released by the developer, and this was often the same code that’s used for the AI, weapons and other game-specific systems. This made it incredibly easy for people to quickly prototype their ideas or, even to just make those simple changes they might want to make. People could also learn an awful lot from this, and it’s essentially resulted in careers for some.

This remained true for a long time. Engines such as Unity were obviously designed around the idea of raw development, however Valve’s Source Engine, Epic Game’s Unreal Engine 3 / UDK, CryTek’s CryEngine and many other engines, included an implementation of an entire game, and more often than not, licensees would often receive more than what they would otherwise be releasing for the public. This was all part of a fairly important package; it wasn’t just about how advanced the engine was at rendering, sound and other capabilities but also about how certain features formed the game itself, such as AI, level transitions, animation handling, client to server communication, inventory systems, vehicles and much more.

The Source Engine is a fantastic example of this because as part of the SDK package, it even includes base content from Half-Life 2, Half-Life 2 Episode 1/2 and Half-Life 2 Deathmatch, which people can use for their projects, and I believe licensees also get the right to use the same content royalty free. The UDK is also a good example, as it includes most content from Unreal Tournament 3.

This all said, I think there’s a problem today. It’s often rare that any game that supports modifications now, will have its code opened up at all for people to delve into. But that’s not the major problem; Unreal Engine 4, unlike the UDK, doesn’t give a complete base game implementation but instead, minor templates. The problem with these is that, while to get something small going is pretty easy, anything worthwhile that’s produced using the templates is actually very unlikely to be using content or code that originates from these templates. The code and content would unlikely be sufficient enough to produce an entire game from, so in the long-term is it actually saving me time or not?

I believe this is actually observable, as it seems you’ll often be seeing larger projects originating from people whom work with the Source SDK or UDK, and smaller prototypes or generally simpler games coming from those working with UE4, unless by people who’re completely proficient in game development. It seems like a shame, and doesn’t make much sense considering the given complexity of modern engines. It essentially seems more of an investment now if a team of people are looking to produce a game, with a reliable framework that can be reused and easily expanded upon.

Now to give some credit, Unreal Engine 4 makes implementing otherwise complex objects incredibly quick and simple; the editor is beyond anything else out there. When people want to add complex elements into their levels or the game, they no longer have to rely on an expert programmer to do it. This is fantastic, don’t get me wrong. The same goes for CryEngine with its flowgraph system. But now it’s less about stable frameworks that can heavily push forward a game and instead seems like it’s more about quick prototyping, I think with a decent framework in place, prototyping could be even speedier if done right while also saving people an incredible amount of time in the long-term; long-term being the most important factor.

It’s sort of like building upon the foundations and discoveries by a previous civilisation, but otherwise most engines today such as Unreal Engine 4 and Unity feel like they throw people back into the Middle Ages, just without the worries of upsetting the church.

I think I can understand the reasoning though, because there’s a fair few out there that prefer writing their game specific logic from scratch, either because it gives them more control or because it also gives a better understanding of how everything works. While working on my project called Decay, I opted to rewrite all the game logic, because I felt doing that would give us a better overview of everything and allow us to write a much cleaner code base in general, not to mention some minor performance benefits since the game code was originally written in QuakeC, however even then, a lot of the code I wrote was inspired by the original QC implementation and that saved us a huge amount of time when it came to implementing everything. In the case of Unreal Engine 4, visual editors for more minor things via blueprints is likely the future of things, however implementations in code will mostly be done without an already existing base implementation to work from; no real references or inspiration, other than the small templates which I already shared my thoughts about.

I think that’s it really, a game based on the Source Engine is very likely to retain and still use a lot of that base game code that Valve provides or at least be heavily inspired by that code. I don’t think this is true in any case for Unity or Unreal Engine 4, but in the end this is just my opinion! And who cares? Y’all get out there and make whatever it is you want to make, and it’s up to you to decide the best way of doing it.

The ramblings of the mad.