On XNA and UIs

HTML UI using Awesomium in XNA

A couple of years ago, while working on my old 'Settler' project, I looked around at the state of user interfaces available in XNA, having little interest in writing the nuts and bolts of my own.

There really wasn't that much, a lot of half working and abandoned projects. Some nice things in C, but my preferred working environment was C#. 

Wanting something a bit more useful in a complicated RPG than a simple shooter style interface, I eventually downloaded a trial of the DigitalRune UI library and fiddled with that.  It worked ok... but come a year or two later when I go back to look at my project the trial key has expired, so now I can't run my old code without either getting a new key or hacking out all the UI stuff.

I decided I wasn't going down that road again, so now I was looking for a better way to do a UI.

Yet More Trees!

So, I more or less ditched LTrees and bought a set of tree models off TurboSquid.  The models themselves aren't much, just three quads arranged in a star pattern.  But the textures are nice, so they look ok, and are very low poly, of course.

Meanwhile, I looked into a newer version of Project Vanquish, and noted I was doing depth calculations a hair different.  I changed the format of the GBuffer render targets to SurfaceFormat.Rgba64 from Color/Color/Single, to allow alpha blending (another thing I picked up from the newer versions of PV).    But, that caused what looked to be clipping in the depth output at very close ranges.  I was doing:

Output.Depth = Output.Position.z/Output.Position.w;

....in the vertex shader, and passing the depth as a float to the pixel shader.  In Project Vanquish it passed the location to the pixel shader, then did the division there, where it was then assigned to the output.  I think this must have resulted in increase precision.

That change seems to have improved the precision of the depth output.  As well as getting rid of the clipping, shadows look a bit better, as you can see above.  Though they still aren't quite right.

LTrees, Instanced

So, it wasn't terribly hard to get instancing working with LTrees, at least the trunks.  I basically used the instancing code I had before, but rather than passing it a Model object, I made it able to accept a VertexBuffer and IndexBuffer combo (which it would get anyway by extracting from the model).  I haven't fiddled with the leaf clouds yet.  I may not, I may move on to set tree models where I can fully control the level of detail, and have billboard imposters at low LOD.

At any rate, it works pretty well.    This is a 3x3 chunk of terrain (32x32x64 sized chunks), so this is drawing more than 9000 trees (simply set now to about 1 per cell), all at full detail and still managing ~ 30 fps.  That's without any real optimization.

The shadows aren't working quite correctly with instanced item though.  Dunno if I will worry about that for the time being.

I did pull some updates from the newer versions of Project Vanquish.  I need to sit down and figure out if I've done something to mess up the shadows...

The Grid

No, this isn't a Tron post... Heh.  Anyway, a while back I read a question on (I believe it was on gamedev.StackExchange.com) about drawing a grid over terrain.

There were some questionable responses, far more complicated that it needed to be.  I've implemented this quite simply in my terrain shader:

Triplanar Texture Mapping, Part 2

Well, I wasn't completely happy with the triplanar mapping I had done earlier, so I decided to revisit it briefly.  I've redone after reading bits of GPU Gems 3 again, in what is a simpler manner.  The terrain drawing pixel shader now is:

Hardware Instancing

I ran into a few problems with hardware instancing while finishing up the basic grass I have been adding to my XNA terrain engine.

Instancing is used to draw multiple copies of a given item.  This is commonly used for grass and foliage (see virtually any game with a landscape).  There can be hundreds of these objects.  A very nice example of this, in my opinion, is Lord of the Rings Online:

 The naive solution is of course to draw them individually.  That in fact is what I did at first, when I was working to simply position them on the terrain (matching the height of the terrain at a given point was the trickiest bit).

This is terribly slow.  Doing so reduced my FPS from 60+ to about one.

Basically each draw call has an overhead, whether it is a large and complicated mesh, or a simple rectangle that will have a small grass texture.  The collective overhead of doing 1000 or more draw calls simply grinds the application to a halt.

Triplanar Texturing

Something I'd been meaning to get around to was improving the terrain texturing.  Steep slopes produced artifacts:

It All Began When...

...My friend Max decided we should make a game.  Easily said, more difficult of course to do.  I'd done a little game-ish programming for fun over the years, most recently a sort of 2D prototype game, which I'd been inspired to make as a Dwarf Fortress / Minecraft sort of thing (I didn't realize at the time that Notch had been aiming for a 3D Dwarf Fortress, and ended up with something quite other, much to his benefit).