Since most of the gameplay in Overgrowth takes place outdoors, it is very important to have a sky that looks good and renders fast. The fastest possible way to render a sky is to just draw an image to the screen, and the best source of realistic sky images is reality, so all of the skies in Overgrowth start out as simple panoramic photographs like this one:

Once it is loaded in the engine, it is converted into a skybox, then blurred slightly for specular reflections, and finally blurred 90 degrees for diffuse lighting and fog. To make the sky and the terrain look like they belong together, we use the blurred sky cubemap as a lookup texture for ambient lighting and for distance haze.

This sky rendering technique is very powerful because just by changing the sky texture, we automatically change all of the ambient lighting and distance haze, so the whole scene still fits together. Using traditional techniques we would have to painstakingly tune each of these parameters, and still end up with inferior results! Here is an example of replacing the sky texture with an entirely different one, changing the whole feel of the scene:

Hey guys, we are continuing our experiment with open development. So far it's been a success! It's Monday, so as promised: another week, another alpha. Per tradition, it has been posted in the secret preorder forum.

Here's what's new!

- David made some improvements on the way the Phoenix Engine handles the sky and shadows. Look for blog posts featuring these soon.

- Massive progress on the multiplayer browser! Last week we announced that we reached a pretty big milestone in multiplayer, with the ability to join a server and chat with your buddies -- now we actually have a first stab at a UI for finding servers! For some reason, it is very pink right now. Don't judge:

- Great improvements in the map editor. Phillip, John, and I made a kick ass level in LittleBigPlanet this weekend, which represents many hours of research on LBP's map editor. Expect to see a lot of LBP inspired features in the coming weeks. This week, Phillip continues to polish up the basics with the ability to select multiple objects at the same time and seamlessly copy things with the alt / option key. He also fixed a number of issues with the editor.

- Tooltips. Our tooltips are hot. They have a graceful fade in / out animation when your mouse moves over things.

- Some hot new art and models from Aubrey.

Finally, we are all testing Phillip's map editor tools and building little houses in the game for fun. Aubrey, our kick ass artist, is in the middle of some other stuff, so for this alpha, the default level is Phillip's "house". We are kind of having a competition between the programmers to see who can make the best house -- luckily, Phillip's looks kind of funny. Also, new rule, this counts as his final entry.

As always, see you guys in the Wolfire forums and in IRC.

To define the surface material of each object, we have a diffuse(color) map that defines the color and subtle shadows of the object, and a specular map that defines which parts of it are reflective. We then multiply the diffuse map with the diffuse lighting, and multiply the specular map with the specular lighting, and add them both together to get the composite result. We will discuss how exactly we get the diffuse and specular lighting in a later post!

One of my biggest goals for the Overgrowth graphics technology is to minimize the 'cgi look' that is common in games and movie special effects, where scenes don't quite look like they fit together. I think we can drastically reduce that effect by simulating ambient and indirect lighting: how each object reflects the color of the sky and nearby surfaces. Most games approximate this by just adding a flat 'ambient light' value to the shadows, but we are going a step farther and using blurred cube maps to simulate the true ambient light colors in every direction.

Since we announced Overgrowth, we have been doing a number of small interviews with various sites. We will probably post a compilation at some point, but one inteview in particular really stands out: GameCyte's interview with David Rosen. I'd like to highlight this one, because it's really well put together, is an interview of our fearless leader, David Rosen, and just kind of kicks ass. Please check it out if you'd like to know about the history of Wolfire (a.k.a the history of David) and just get a more personal behind the scenes look at our humble project.

Here's a snippet:

GameCyte: When did you first decide you wanted to develop an independent game? How long before your first serious project had you been dabbling in game creation?

David Rosen: Oh, man, I created my first independent game long before I even knew what independent games were! When I was in Kindergarten, I started creating finger-games with stick figures walking around that took verbal commands from my friends and acted them out. When I was introduced to HyperCard in 1993, I was 7 years old, and I was quickly hooked on making my own animated choose-your-own-adventure computer games. They had stick figures at first, but gradually improved until they were in full 3D, painstakingly hand-animated. Unfortunately, none of these games exist today because of a dispute that resulted in my hard drive being erased, but they may still exist somewhere in the far corners of AOLs mac game archives, from back when AOL and Internet were synonymous.

Check out the full interview here.

Hey guys, here is the first part of the long ago promised post on our terrain simplification. Like most other 3D games, we're generating terrain meshes from heightmaps. The easiest way to do this is to just sample from the heightmap at regular intervals and place corresponding vertices on a regular grid. Unfortunately, this can lead to chunky looking terrain and lots of wasteful vertices that add little visible detail. So, for our terrain, we decided to go 'off the grid'.

Left: Boring, on-the-grid terrain. Right: Fancy, off-the-grid terrain. Both meshes use ~21000 triangles.

Instead of placing vertices on a grid, we place them at irregular intervals. This has at least two advantages. First, our irregular meshes look more 'natural' than regular grids would (if you remember back a bit, before we had texture mapping, this is what gave our terrain it's crumpled, faceted look; even with the texture map, I think the irregularity of the mesh makes it feel less rigid than usual, as you fly about over it). Second, we are free to optimize to our heart's content: we can place lots of vertices in high detail regions and cut back in flat regions.

In order to optimize, we have to figure out which details, exactly, we want to preserve. We've been thinking a lot about what aspects of terrain contribute most to its visual impact. Since we cover the terrain with a high resolution texture map, the underlying mesh is usually hidden. However, silhouettes of the terrain still reveal its actual coarseness. Taking this into consideration, we're spending most of our vertex quota in terrain regions that are likely to form silhouettes. Ridges and peaks stick out the most, so they tend to form the silhouettes, and and thus they get first priority for vertex use.

Despite using the same number of vertices as the on-the-grid mesh (left), the off-the-grid mesh (right) has silhouettes that are much more precise.

It's also visually important to allocate detail for sharp valleys and creases in the terrain, since crease lines pop out to the viewer but are limited to following mesh edges. Luckily, such creases are just inverted ridges, and so we can treat them similarly to how we treat ridges. For the desert landscape in the pictures above, ridges really dominate, but for other landscapes (such as those with creeks, gorges, and chasms) creases will also be very important. Coming soon, I'll fill you guys in on how we actually find the ridges (and inverse ridges) we want to preserve!