In my test arena, I had some performance issues in same places, where about 9 lights were shinning in a greater or smaller degree…
Considering that in a deferred renderer, the main issue is bandwidth (each shaded pixel needs at least 64 bytes of data to come in from texture memory – the G-Buffer), I thought that the best way to lessen this impact was to render the light volumes, instead of just drawing a rectangle that approximated the light.
Starting off, this is my test scene:
The merge tool is finally done, and while it was a truckload of work, it was worth it for the amount of small bugs I found… Nothing was too serious or hard to fix, but most where quite complicated to find and would be hard to fix later!
I’m finally finished with all the detours I’m willing to let myself make, and started working on the arena itself…
Work has been progressing slowly, since I’m always finding small bugs and we’re still fine tuning the visual aspects of the game…
Most of the work is converting the old code I had on the prototype to the new framework I’ve built, looking at the code to see if there’s something that can be improved, since what I’m going to do on the next weeks is going to shape most of the code development process…
From a visual perspective, we’re not too happy with how the shadows are behaving… If you look at the above screenshot carefully, because we have two lights at the same distance and with the same intensity, there’s no visible shadow on Grey, which doesn’t make me happy (it seems like he’s floating in the air). If I was using a HDR pipeline, this wouldn’t happen, because between the tone-mapping and the added light resolution, things would work fine… but since I’m avoiding that path, we need to find another way to get better shadowing on the character, like reducing the light amount in the scene or something else…
I’m also not happy on how specular highlights are showing up when the characters are this small, since they tend to just “jitter” a lot… Maybe I can fix that by reducing specular highlights on the mipmaps…
There’s also some issues with the precedence of some animations that has to be sorted, so that he doesn’t go into “idle mode” while he’s walking…
Anyway, lots of work ahead, but this is fun code to do (albeit frustrating sometimes…)
Sorry about the lack of updates, but the day job was hectic and I had some personal stuff to sort out…
Even so, I’ve had time to make another detour in terms of development roadmap and started building a “project merge” tool…
Everything we’re doing in Grey is done on the SurgeEd tool, which manages the project (all the resources, maps, scripts, etc). But me and Rincewind both work on the editor, in different elements: for example, he assembles areas, and I had the scripting elements to make it work, and eventually we have to join our work. Although all components are in different files, the probably of screwing this process if we do it by hand is pretty big, and as such I decided to build a tool that allows me to merge two different projects.
This tool allows me to selectively merge components, choosing what I want from one or the other, comparing entities, etc. This has been a very complex tool, but it’s almost done.
Hopefully this will allow us to streamline the whole process of building areas!
As I stated on the previous post, I didn’t have time to work on Grey this weekend, since I was participating in Ludum Dare’s 48-Hour Game Development Competition… Before you ask, it didn’t go that well, since I couldn’t come up with a decent idea; I just ended up doing a Voxel World editor… If you want to read some more about the competition, you can check out my personal blog.
Anyway, I had time to add three things to the shadow systems:
First up, I added the “Shadow Cluster”… This works similarly to the Geo Cluster I described in a previous post, but it’s much more simpler, since I use it to store the necessary geometry to render the shadows for all the static objects in the light’s radius. Since I only need vertex positions to render the shadows, it makes for pretty small buffers, that are lightning fast rendering!
This gave us an improvement of about 100 FPS in our test scene…
Another thing I messed about is “light volume culling”. Before I was drawing all the objects in the scene to the shadowmaps, even if they weren’t in the light’s radius, but now the system does culling and as such only renders things that actually need to cast a shadow.
Finally, I added an option to enable a small trick…
Until now, all lights needed to have a “shadow epsilon” value tweaked on each light, which would do a small bias in the shadowmap so that the object wouldn’t incorrectly self shadow itself… This parameter was quite fickle and depended on the distance of the light to the closest object, angle to the light, etc, etc… Even if the parameter was well tweaked for some circumstances, if the lights were dynamic, all bets were off!
As you can see, the light is incorrectly shadowing the bottom-right column (the one closest to the light).
More technical explanation follows:
Most of the time this week was spent (again) on things that were scheduled for later in the development cycle, either because they’re too useful now (the geometry clusters, the shadow clusters) or because I was curious in seeing the results, like the color grading.
From Wikipedia: “Color grading or colour painting, is the process of altering and enhancing the color of a motion picture, video image, or still image either electronically, photo-chemically or digitally. The photo-chemical process is also referred to as color timing and is typically performed at a photographic laboratory. Modern color correction, whether for theatrical film, video distribution, or print is generally done digitally in a color suite. Considering such achievements in digital imaging, the artist has the ability to "paint" the image, thus the names "colorist" or "color painter" have become most applicable.”.
In practical terms, color grading allows the artist to change the overall mood of a rendered frame of the game by changing the colors. For example, if the artist gives the scene a slight blue-ish hue, the scene will look colder, while tinting it red will make it look more dangerous…
On the left side of the image, you can see the pure render (without any color grading). On the right side there’s an example of color grading (exaggerated so the effect is immediately noticeable… the normal effect should be more subtle). The right-side panel gives a feeling of imminent danger (at least for me).
This weekend I worked on a major optimization; I was supposed to work on this after the first milestone was done, but I had serious enough performance issues to warrant the work now instead…
The problem is related to the amount of objects. Most objects in Spellbook are composed of loads of triangles, but in today’s modern video cards (and not so modern anymore), it takes more time setting up the geometry, textures, shaders, etc, than actually drawing the objects!
To stress test the system, I created a scene in the editor with a lot of trees (a kind of forest):
All of these are independent objects, each with its own position, orientation and scale. There’s about 200 trees in the scene, and with just one directional light with PCF shadows, it ran at about 40 FPS, which is completely unnaceptable for this ammount of objects…
Long story short, I fixed it, and the scene now runs at 60 FPS with 20 point lights or so (images after the break).
Below, technical explanation on how we did this:
There are several problems at work here:
All of these can be solved using the same “tool”: GeoClusters!
A GeoCluster is basically what I call to a bunch of geometry that I grab together and combine in a single object… In the case above, I grabbed all the trees and placed it on the same object… In the context of the editor, I just build an aggregate object with all the objects I want to combine, right-click on it and select “Build GeoCluster”. This will trigger an internal system that joins objects together in the same “primitive”, so 200 objects basically become 1! Drawing becomes super-fast and GPU limited, instead of CPU limited as it is without the GeoCluster.
The GeoCluster isn’t limited to “similar” objects, they can be completely distinct. In that case, the GeoCluster will join geometry that has things in common (mostly textures). So imagine I’d have 2 types of trees with completely different textures. The GeoCluster would create two meshes internally and send each type of tree to the correct one.
The system even has a more advanced mode, in which it can combine objects with completely different textures in the same mesh, by using a texture atlas, which is a kind of lookup texture that aggregates a series of textures. The system can generate an automatic atlas, using the GPU to do so (no human intervention or storage required).
This is supposed to be used as a pre-process stage, since the generation of a big GeoCluster can take some time (the one above takes about 100 ms to generate, which doesn’t seem like much but it kind of stacks with all the rest of the loading process).
I’m very happy with this optimization, since it makes everything run much more smooth and allows me to increase the quality of the shadows (for example using cube-maps for point lights, instead of dual-paraboloid maps which have much less resolution).
In the process of testing this, I became disappointed that Grey won’t feature any forests in this episode, since the end result is very cool (for just one type of tree and no regard on placement, as I did above).
Here you can see a closeup of the tree. Note that anti-aliased self-shadowing with a low-res shadowmap (256×256 for the whole area)…
A closer look into the forest… In this test, I had 20 lights with PCF anti-aliasing: a big directional one that gives some light directional luminance to the scene, and some short-range purple omnidirectional lights for “ambience” 
I’m just wrapping some additional things on SurgeEd (think most of the bugs found are solved now), and I’ll jump into the game code itself (although next weekend I won’t have any time to work on Grey, since I’ll be participating on Ludum Dare’s 48-Hour Game Development compo)…
This weekend was spent mostly with family, so not much progress was done on Grey, besides fixing one million small bugs and nuisances in the editor, per artist suggestion… It will take me forever to get used to the new key/mouse bindings!
Anyway, had some tricky problems in the editor that were only apparent when we tried using the editor in real circumstances, namely the building of the arena.
The arena has a 40×40 tile area (which means about 80×80 meters)… Since in the editor the objects have to be individualized (so they can be worked on), this means that the ground alone is made up of 1600 objects, which stressed some of the less efficient systems in the editor, making it almost unusable.
One such systems was the rectangle selection system, which grabs the object’s bounding box (recomputed every time it is requested), transforms it to screen coordinates and matches it with the given rectangle… For 100 objects, this is ok, but for 1600 it was really slowing down the system! It’s fixed now, but it was hard tracking the exact problem (since I can’t find a decent free profiler that works on my editor)… Initially I was panicking thinking the renderer was dying with just 1600 objects.
Anyway, the editor is a bit more stable, a lot more useful and work continues to progress in the building of the great arena…
Just the ground, for your viewing pleasure:
I know it looks very “8-bit”, but that’s because ambient intensity is cranked up to maximum, there’s no directional lights (so no normal map details), and we’re too far away (so the chaos in the textures just makes that 8-bit look). Hopefully in the next days we’ll have the time to fill it up with some more assets, and I figure that after we add the real lights (and shadows) and the color-grading, it will look great!
If you want something you’ve worked on for some time (specially tools) to break, give it to an artist! 
We were supposed to start working on assembling the arena for Grey in the beginning of the week, but as soon as Rincewind grabbed SurgeEd, I found one million bugs and I spent most of the time fixing them!
There was something for every taste: bounding box problems, sampler issues on the automated tiles, small UI issues…
The bulk of that time was lost with sampling issues… On a previous post, I explained that we’re going to use a tool to build the actual tiles, from simpler textures and some masks.
On my tests, the tool performed rather well, but with real data (made by an artist), the result was terrible… When the camera is away, you don’t notice (unless you’re actually looking for it):
But as soon as you zoom in, you get these ugly seams…
After a big fight in these last nights, I got rid of most of the critical bugs in the editor, which means that me and Rincewind will start assembling the arena for our first milestone… I wonder how long until we find the first critical bug! 
The idea behind the first milestone is to have an internal version of the game running in which we can test the first battle, pitching Grey and some Lava Imps against some Skeletal Wardens, Fighters and Berserkers. The UI will still be my own (the ugly, box based stuff), which sucks, but we’d rather have the game in working condition before actually working on the UI (after we actually figure out how the game plays, what kind of operations are more common, etc.).
We have some challenges ahead in this first milestone, like rudimentary AI, path-finding and (I think will be necessary) shadowmap rendering (my current shadow rendering might still be too slow for actual use in a real scene with plenty of lights).
In parallel, we also want to have finalized the game poster (including the game logo, etc.)… and we want to make 3 videos: a short teaser trailer, a gameplay video and some sort of “talk about the game video”, so we can start trying to get some awareness for the game… Hopefully this all will be completed between mid-April and May.
Our approach to game development here in Spellcaster Studios is atypical for a small indie studio (from what I’ve seen in other indie blogs, etc.); we focus a lot on tools, which means that the beginning of the project is quite slow, trying to get all the tools and basic internal systems up to speed; gameplay code is done in a very data-driven fashion, which means that internal systems take a lot longer than in “hard-coded” cases… Also, getting the art pipeline to work while the renderer is still in flux is a challenge! Still, we believe this is the best way to work, even if the beginning is slow, since the further we’re along in the project, the faster it goes (which is usually the inverse you have in most indie projects I follow).
So we have a bit more visuals in this talk-talk-talk post, here’s a couple of screengrabs of Grey summoning the Lava Imp (everything except the models done by a programmer!):
Anyway, wish us luck!
Rincewind is almost done with the skeletons and is working on some props:
The armor pieces, swords and shields are done through mountpoints in the model itself.
The skeletons are low-tier enemies in Grey. A necromancer can animate skeletons nearby, but usually only the spirits of people slain violently heed the call of the caster and re-enter the skeleton to do battle once more. The skeleton is a brittle opponent, depending mostly on physical attacks, since the remaining spark of life is too weak to use magic, although a talented necromancer can channel some of his own life to the skeletons to imbue them with magical powers.
A life-shaper like Grey can also create skeletons, but its like a facsimile of a skeleton and not a spirit inhabiting his former body…
More images after the break: