||||A New Music

I’ve finally admitted it to myself: CPU-based terrain generation just isn’t smart, and it’ll probably get crushed by all things GPU-based in the future. Sure, it makes threading and precision easier to deal with, but it doesn’t make sense that my current terrain takes about the same amount of time to generate on my Intel HD Graphics-driven laptop and my 560GTX-powered desktop. Why on earth are all those processors going to waste?

So, here we go. My second endeavor into GPU-based terrain generation. I’ve already come farther than last time, when I gave it all up because of cracks that I thought were the result of GPU precision problems. I managed to solve the crack problem this time. Of course, my skirts were hiding the problems, but it still made me uneasy that tiles didn’t line up perfectly – luckily, a little math solved that.

It may look like the screenshot is a regression from my previous shot, but, since it’s GPU-generated, it definitely represents a step in a direction that I think will ultimately prove to be a worthwhile investment in the future of XDX’s terrain engine. The terrain below is obviously simple: just a single layer of iterated value noise. Building up layers is the next step, and should be relatively easy with a few shaders.

I’m getting a bit better with terrain functions. Slowly but surely…

I started working with preliminary texturing on the terrain, aiming to get some pleasing variation in texture patterns. Everything is still horribly ugly due to the lack of nice textures for grass, dirt, etc. I’ll have to go back and revisit procedural textures soon, as the texture quality is becoming an ever-more-noticeable bottleneck on this terrain.

The sky also looks a bit better now. It’s not “real” in the technical sense, but at least the gradient looks better than before.

This terrain experiment is shaping up to be a decent little demo…I hope to evolve it into an integral part of the XDX engine over time.

Still working with the new terrain engine. I’ve decided that overlapping and praying just isn’t the right approach – it’s way too fragile. Constants like overlap factor and skirt displacement have to be tweaked to perfection in order to get a non-cracked terrain. Rather than spend my time searching for the perfect constants, I’ve opted for a more fool-proof approach: skirting.

So far, I’m extremely pleased with the results. After fooling with normals and texture coordinates for a bit, I’ve reached a point where I can’t see any anomalies in distant terrain, other than discontinuous normals. Of course, the discontinuous normal problem is a common one and should be easy enough to fix.

When I get some more time, I’ll start the arduous process of making it adaptive. Luckily, I expect to face far fewer threading errors this time, since the tiles operate totally independently of one another.

I’ve expanded the previous “Strange World” demo into an adaptive landscape demo. Several months ago, I learned the pain and agony of trying to write a fast, multi-threaded adaptive terrain engine. As a result, I’m now experimenting with easier systems. At the moment, all I’ve done is taken a very rudimentary patched-terrain system and implemented some hacks to eliminate T-junctions. I also scattered some tree trunks around the landscape.

It’s actually not looking too bad! I’d like to continue using this sandbox to mess around with vegetation and building coherent terrain regions.

Yes, those grid-like procedural textures really need to be replaced

I’ll admit that the following screenshots don’t depict the most attractive procedural world ever, but I think they’re a step in the right direction. It’s just proof that I’m able to build larger-scale works of proceduralism. I’ve been slowly building up the small, individual components for a long time, and I’m starting to get antsy to move on to the larger work (the combination of elements).

The scene uses the procedural texture generator that I’ve been working on. The generator is still not suitable for organic/natural textures, which is why the grass, mushroomy things, and sky all seem to have a metallic quality to them. Still, everything here is procedural, and that’s the point.

I’m tired of posting great content with no textures!!! That is why I will be devoting more time than usual to finding some decent texture functions: so that future cool stuff will look cooler. I’m having a great deal of fun tonight with building a random texture generator…

Tonight’s verdict: tiled, alien-ship-hallway textures? Solved. Organic textures? Still an open question.

Experimenting today with a new procedural technique involving extrusion of a polar function. Implemented a random equation generator and evaluator. Not particularly interesting or coherent yet, but I could imagine this being cool in the future with enough honing and exploration of the space of random equations.

I’ve taken a break from my research for the past week to work on an intense, one-week game project. For a graphics class assignment, I decided to challenge myself to see how much of a full game I could write in a week. Here’s the catch: we’re using OpenGL in the class…and my only experience is with D3D. So the past week has been an incredible flurry of learning OpenGL, ridiculous amounts of coding, and learning how to build a real game (rather than the small demo-ish things that I usually build to explore single ideas).

The result? I’m proud to say that I ended up with a very respectable little space shooter by the name of “Epsilon.” I wrote it from scratch using GL and c++. I tried to rebuild a very small subset of my D3D engine’s functionality, so that I could work with the same abstractions to which I have become accustomed. The final game .cpp files had no GL-specific code in them, so I succeeded in that respect! I think it’s going to be easier than I thought to make my engine multi-platform (i.e., both D3D and GL).

The most interesting part of the project was learning to do new things that I’ve never done before, rather than just applying knowledge that I already had. Indeed, I tried a *lot* of things that I had never tried before, including the following:

Modular Architecture. Each module handles some subset of the game’s functionality, making it far easier to keep things clean, separate, and manageable.

A Particle System. The particle system pretty much made the game’s graphics.

Procedural ships via radially-extruded shapes using multiplied sinusoidal radius functions. The idea ocurred to me when I was searching for a quick solution to procedural ship meshes. I just extruded rings and applied a radius function. I tried a sum of sinusoids, but decided that multiplication gave nicer results. The results are pretty decent! My previous box ships are still better, but I didn’t have time to do a full perlin implementation for this game.

Cutscene. I produced a short cutscene at the beginning of the game that sets up the story. I experimented with camera transitions, cool text effects, etc. I’ve never done anything cinematic like that before…but I was really pleased with how it turned out! Of course, I don’t think it’s really relevant – I don’t plan on having cutscenes in my future games.

Sound!!! I used the BASS library to get music and sound effects in the game with a remarkably small amount of work. I’m really excited about this, and it may just be the thing that I choose to do sound in my engine (though I’d still like to learn how to use DirectSound by hand).

Font Rendering Engine. Font support was very limited in GLUT, so I rolled my own font rendering system that built strings out of quads. Although the system was pretty primitive and hacky, it turned how surprisingly well. I coupled this component with the particle system to allow rendering of fonts in particle form, which was cool!

Some screenshots of the game:

Title Screen


Intro Cinematics


Into the face of the enemy.


That’s a lot of missiles…

I had a pretty exciting night with planet generation. I was trying to come up with some clever math hacks to circumvent having to use a 3D noise function, but in the end gave up and defaulted to the standard cylindrically-wrapped-3D-noise-texture approach. The results are very nice, but take too long (~6 seconds per planet). I’ve been working on a super fast Perlin implementation, but I don’t know if it will be applicable to the 3D case (because of the insane amount of memory it would require). In all, I’m excited about these visuals, but concerned about how sustainable they are if I’m unable to come up with a way to cut down on the computation time.

I also took my shader from the recent scattering study and improved it a bit, resulting in what seems to be an appealing (although completely unrealistic) atmosphere.

At the very least, I seem to have finally nailed the proper color gradients for an attractive Earth-like planet.