Hardware Instancing with Texture Atlases

I don't know why this sprang to mind... Dr. Frank-N-Furter: "He carries the Charles Atlas seal of approval."

Atlas texture.... without atlasing!  This should be one tree.

I've accomplished one last thing with the trees and instancing (I just got back from a week long business trip, can't you tell I've had all these ideas pent up?).

Having only one sort of tree at a time was a bit limiting, so I decided to try my hand at adding a bit of texture atlas functionality to my instancing.  Never tried it before, but in theory it is pretty simple.

There was always a single texture passed in to the class that set up the instancing, now it can be an atlas instead of just an ordinary texture.

Well, it could have before, it just would have been silly as you can see above.

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 Return of LTrees

In my original code, way back when I was basically working through Riemer Grootjan's excellent tutorials, I stumbled upon LTrees, a procedural tree generation system that worked with XNA. It was really quite straightforward, and I easily added it in.

My current voxel implementation is more complicated however, and adding the intricacies of deferred rendering (I swear I will eventually get around to discussing Project Vanquish and what I've been doing with it), I'd put off re-integrating it for a while.

I've finally done that, and it was mostly easy. Generally speaking I had to change the shaders to deal with deferred rendering, adding normal and depth to the pixel shader output. I've not fiddled with getting shadows to work yet, but I can see my way through that.

There are two other real issues left. The first is alpha blending on the leaves. Alpha blending is a bit of an Achilles heel for deferred rendering setups.  The funny light coloring around the leaves is due to the alpha problems.  The second is that... well the naive implementation of simply drawing a lot of trees works slowly, of course.

So, I'm working to implement LTrees, but make the items themselves instanced.  That will take a bit of work, so in the meanwhile, these images are what it looks like now.

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.