Maximum of 7 lights touching each chunk in the terrain shader, but chunks were far too large due to CPU limitations on the XBOX.

To this end, I’ve been exploring some deferred lighting options.

For the Xbox 360, an attractive option is light-pre-pass, which suits the Xbox much moreso than a fully deferred setup, as LPP uses less intermediate texture buffering, and therefore avoids Xbox 360 texture bandwidth limitations, and avoids predicated tiling issues.

J. Coluna has a good LPP example, and he was wondering how to deal with the problem of being limited to 32 bit render target formats on the Xbox 360, yet wanting to store specular light data in the light buffer (for which I use HDRBlendable, on the xbox this format stores 10 bits for RGB and 2 bits for alpha).

I’ve put in somewhere between 500-900 hours into this project (schoolwork being mixed in there makes it hard to estimate), and I think that I’ve been very productive in that time. The project is now 8300 lines of code, in about 187 class files.

So, why didn’t I finish in time for DBP? Here are some of the mistakes I made:

• Overambitious project goals.
• Picked wrong light rendering design for the design of this game.
• Underestimated the complexity of implementing some design ideas, such as the terrain, and the lighting set up.
• Focused too much on building clean, pretty code, instead of hacking together a finished game.
• Spent too much time building the game engine, and too little time building the actual game logic.
• Spent two weeks building my own physics engine from scratch, instead of using an existing engine.

Here’s a composite of a few screenshots of my Git commit history:

(Click to enlarge.)

I tried to choose a game concept that was as simple as possible, while still maintaining some of the key elements from my 100+ page outline of a much more complex game.

That said, I was still far too ambitious for a 3 month project. I think that any 3D game that can be competitive with a 2D game is going to take a lot of extra time to polish well. For example, I didn’t realize how much time triplanar normal mapping would take to get right. It’s simple in theory, but getting the slope angles just right, getting the transitions between texturing planes just right, mapping the normal maps onto the correct plane, etc, etc, all took a lot of extra time.

Before deciding to do this project in first person 3D, I read that many people avoid indie 3D games because creating the artwork takes so much longer (or they can’t do it themselves). As one example, it took me about 45 minutes to create the doll enemy model (pretty quick, no?). I figured, well, I can create a 3D model of an enemy in ~45 minutes, so 3D artwork is not a big deal — I’ll just go make the next Halo now!

In reality, the artwork is no big deal. It’s really everything but the artwork that makes 3D much more work than 2D, especially from a first person perspective. When I say “artwork” I mean 3D models, textures, texture mapping, animations.

In a first person perspective, you can see thousands of meters into the distance, but also if the player looks straight down at the ground, since only a 1-2 meters are viewable, we expect to see a great deal of detail. Managing detail at close and far distances well is an order of magnitude harder than managing detail in a 2D game. In a 2D game, or even in a 3D game with a relatively fixed camera perspective (e.g. Starcraft or Diablo), you know how much geometry can be viewable in the worst case, and there’s much less detail scaling needed.

As an example of detail scaling, getting terrain detail to scale well in this game was done over the course of many weeks. Indeed, it’s still not perfect. If you’ve tried your hand at realtime 3D drawing, then you’ve probably done a terrain. However, you may not have encountered the mess of fading textures and specular/normal/emmissive maps between detail levels. I used geometry instancing for the distant chunks, which meant no lights in the distance in my lighting model. Things like this added up quickly.

I thought a bit about what the title of this post should be. A reference to Duke Nukem Forever felt appropriate at first, until I realized that it’s probably not fair to compare my 3 months of development to 14 years of off-and-on DNF development. Hell, even if I am writing DNF-level vaporware, at least Duke Nukem Forever is finally being released, right?

Anyways, terrain-sphere collision works now, and the new terrain engine is integrated into the game. Simulating 400 spheres on the PC takes only ~3ms per update (single threaded). This should make 400 spheres viable on the XBOX 360, which will have about 33ms per update on a CPU core dedicated to physics. This is about a 5-10x speed increase over the performace I was seeing with the default BEPU physics setup.

Sphere-terrain collision.

The new physics engine in action: 350 spheres colliding against 4 intersecting planes.

I’ve been looking for a good physics engine for this game for a while now, and my favorite so far is BEPU. If you need a physics engine for your game, BEPU is pretty awesome. They went open source just recently, and their simulation is extremely stable and pretty accurate. They support all sorts of constraints, and Norbo is constantly monitoring and responding to questions on the forum.

That said, my game idea relies on having potentially hundreds of spheres in the world at once, and with an entire single CPU core devoted to the physics on the XBOX (plus the physics management on the draw core) I was only able to simulate 20-30 spheres at a 20FPS physics update, and that was only if they were all reasonably spaced apart.

However, I don’t need the precision of BEPU, and for most spheres, I don’t care if they have accurate 3D angular momentum. BEPU also doesn’t exploit the properties of my game world, such as the fact that physically simulated objects are rarely on top of one-another. So, I decided to write my own engine, taking all of these special cases into account.

Paul Firth wrote a post about speculative contacts, a continous collision detection approach to physics simulation.

Using this idea, I’ve created a simple CCD physics engine. While there are drawbacks to this approach, it’s suitable for my purposes, and remarkably stable with just one solver iteration. This together with the exploitation of the special case for physics in this game, should prove to be much more efficient.

Above is a recording of the engine in action. Sphere and plane collisions are currently handled. This is 99% of the work for sphere-terrain collision, which is almost everything I need to add this into the game.

This physics engine already uses the same spatial partitioning approach used in the game (two grids which act as the bottom two levels of a complete quad-tree).

I decided that only having ~30 lights visible at a time on the xbox wasn’t enough, so I spent yesterday implementing a new level of detail system. How many lights the XBOX will allow when everything is in the scene is to be determined, but for now I can estimate that about twice as many will be possible (50-60 point lights visible at once). That’s a lot more than you’d expect from a forward rendered game on the XBOX 360, typically.

Distant blocks now take up 1/4 space, and will be scaled up -- similar to a quad tree implementation.

1/4 size blocks are now scaled up.

Color coded levels of detail.

Blocks have been slightly separated to make them visible.

Yesterday the game ran on this PC at a meager 20-35 FPS. Today it runs at well over 300 FPS thanks to the new GPU.

302 FPS on the new GPU.

Oh how much easier this development would be if I could just run the game on this PC…

Anyways, now that I have a new GPU; gameplay vids incoming!

Point light stress testing.

Point light stress testing.

Since this was so slow, and I want to associate a point light with most enemies, I’ve been optimizing the partitioning a bit without making any very drastic changes.

Since there’s only about a month left, I decided that the smart thing to do is just to reduce the size of the terrain, and reduce the number of lights, in order to get everything done. Once it’s all working, I’ll consider revising the partitioning system to support a larger world again, and add more lights.

Below is the current state of things:

Point light testing, and some spheres rolling around on the terrain, colliding with each other.

After optimizations, this runs at about twice the speed that it did yesterday.

Struggling to get things working fast enough on the XBOX CPU (which provides me with roughly 10% of my PCs processing power) has been slowing me down a lot. Things that I keep expecting to be more than efficient enough, turn out to be twice as slow as what’s really feasible.

The image above has only 270 point lights spread out across the terrain (the little blue particles, only about 30 are visible), but runs at about 65FPS on the XBOX, limited by the CPU. That should hopefully be enough for the state of the game at the competition deadline. Far more lights, and a much bigger world is possible — but it’s not looking like I’ll have time for more than this before June 14th.

Slope based texturing. 3 textures applied at different slopes.

In the image above, a dead grass texture is applied to flat portions of terrain, a green texture on the edges at intermediate slopes, and a (very stretched) rock texture is applied to the steep slopes.

The stretching of textures on the very steep slopes can be corrected by projecting the texture from a different plane. Currently all texture coordinates are produced by projecting the textures from the XZ plane. The steep slopes require projections from the XY and YZ planes though, so I’ll work on that tomorrow. Edit: texture projections for steep slopes are now complete.

I’ve refined the culling method to test blocks against an arbitrary polygon in 2D space.

Arbitrary polygon displayed with red lines. Terrain chunks that do not intersect this polygon are culled.

This method takes 0.5ms using a 6 vertex culling polygon — 8x faster than testing the camera frustum against terrain chunk bounding boxes. This in turn gives me enough room on the CPU to potentially quadruple the number of terrain chunks, and increase the number of lights, and the terrain detail.

This allows me to use the trapezoid of the camera frustum projected onto the ground plane to cull the terrain, like so:

The camera frustum projected onto the terrain grid forms a trapezoid.

Image courtesy of this forum post.

This trapezoid however, is not enough. The shape needed is a projection of the entire frustum onto the terrain. I thought that wouldn’t be too hard, but it took ~12 hours to complete.

My method for finding the culling polygon desired, is to find the trapezoid above by intersecting the frustum rays against the terrain. Then project the near plane onto the terrain plane (good enough for our purposes).

Then take the resulting projected points and find the convex hull that surrounds them.

On the left, a top down view of the camera frustum (projected onto the terrain). On the right, the convex hull resulting from the edges of this projection.

The red lines display the shape of the culling polygon produced from projecting the camera frustum onto the sea plane.

Although this took much longer than expected to implement, along the way I’ve implemented ray-terrain intersection testing, convex hull from point cloud creation, simple polygon point list winding (i.e. take a convex hull and produce the list of vertices in clockwise winding order), and point in polygon testing.

These tools will come in handy very soon, as monsters and more physics are introduced into the game.  For example, I can now compute a bounding polygon for a monster, instead of just using a bounding sphere/box.

Now that things are being drawn reasonably efficiently, I can finally start to implement some interesting game mechanics. Stay tuned for that.

Most AAA titles seem to support something like 5-6 dynamic lights. I’m sure you’ve noticed by now that this game takes place mostly in the dark, and I plan on making it darker still (if I can). Well placed lighting will play a big role in making things look interesting, as well as just being able to see your surroundings.

Pre-pass or fully deferred rendering would allow for many lights with little work, but these rendering schemes don’t support MSAA or, more importantly, transparent objects. Also, deferred lighting is not a very good fit for the XBOX, due to it’s 10MB EDRAM and predicated tiling, and it’s relatively low texture bandwidth. I did spend a little bit of time playing with J. Coluna’s pre-pass rendering code on the XBOX a few days ago, but the lighting quality was very poor when used with the XBOX HDRBlendable format (which is 10 bits per channel plus 2 bits left over).

By partitioning the space into a grid and registering objects and terrain chunks into it, I can currently draw 30 point lights at once on the xbox (at 60 FPS). The CPU speed is the limitation so far, not the graphics card.

Of course, that is with just the terrain. Things will get a lot slower when I start adding trees and other objects.

And I haven’t mentioned shadows yet.

In order to be able to set the game in the dark atmosphere that I’m going for, I’ll want to have at least 20 point lights, though I might be able to get away with casting shadows from only 10 or so.

Dynamic point lights moving across the terrain.

I’ve starting writing some basic rigid body physics. I have projectiles working that can detect collision, but do not react to collisions appropriately yet. Actually the lights in the picture above are projectiles launched from the camera’s position.

I’ve also built a framework for making explosions of various types, complete with flying debris.

A couple of basic explosions with debris.

The explosion above uses a fairly flexible Explosion class that I wrote yesterday, so new explosions can easily be created with little code at this point. Most projectiles that the player can fire will need some sort of explosion, so recreating an explosion type effect will happen often. This could be used to display the destruction of a crate for example. Just replace the explosion particles with subtle smoke, and the debris with broken wood models. Since the explosion debris are projectiles themselves, they can have their own explosions, which can have their own debris, ad infinitum.