TL;DR

Right off the bat, if you just want to dive right in with a state-of-the-art atmosphere rendering technique, then go with A Scalable and Production Ready Sky and Atmosphere Rendering Technique by Sébastien Hillaire. It is the same atmosphere rendering technique used by Unreal Engine, it is fast, scalable, has less edge-cases than previous approaches, and the author has made reference source code available.

On the other hand, if you have more specialised needs, or just want to go deeper on atmosphere rendering, then stick around...

How we got here

There is a long history of realtime sky rendering, but the vast majority have been concerned with rendering the sky from (or at least near) the ground. I'm primarily interested in planetary atmosphere rendering - we want to be able to fly to space and back, with a seamless atmosphere throughout.

For planetary atmospheres, it all starts with Nishita et al's 1993 classic, Display of The Earth Taking into Account Atmospheric Scattering. This is going to lay the foundation for the all the techniques to come, so it's worth the read even if just for the basic concepts of atmospheric scattering and optical depth. It is worth noting that at the time there was no way to run these calculations in realtime.

The big jump to realtime doesn't come until 2005, when GPU Gems 2 is published. Sean O'Neil contributes Chapter 16: Accurate Atmospheric Scattering, in which he uses a 2D lookup table to accelerate Nishita's single scattering approximation. His technique is still in use here and there, as it's simple to setup and produces reasonable results when viewed from space. The major drawback to this technique is that it doesn't account for the effects of multiple scattering at all.

Shortly after, in 2008, Bruneton and Neyret crack the multiple scattering problem with Precomputed Atmospheric Scattering. They use a large 4-dimensional lookup table packed into a 3D texture to evalaute multiple scattering, which can be precomputed on the fly using a GPGPU implementation. Although source code is made public, it's quite complicated, and adoption is somewhat hampered until 2017, when Eric Bruneton releases a new reference implementation, which also improves on the original results. This model is still widely used, and looks stunning in many applications. The main drawbacks are that the lookup tables can cause rendering artefacts in some cases, they are fairly expensive to recompute, and the technique struggles to render very thick atmospheres.

Where we stand today

And that brings us back to Sébastien Hillaire's A Scalable and Production Ready Sky and Atmosphere Rendering Technique in 2020. Hillaire eliminates the big 4D lookup table, mostly by noting that portions of the algorithm can be evaluated at significantly reduced resolutions without loss of quality in the output image. Armed with a set of much smaller lookup tables, he's able to update them all within a single frame, allowing artists live feedback as they adjust the atmosphere parameters. As a nice bonus, elimiating the big lookup table also eliminates a number of rendering artefacts, and he can render thicker atmospheres.

What's next?

The techniques I've covered up until now product great results for Earth-like atmospheres, but ideally we'd like to be able to render all sorts of planets, and we'd also like to be able to keep pushing the envelope on rendering fidelity.

With that in mind, Interactive Visualization of Atmospheric Effects for Celestial Bodies, and Physically Based Real-Time Rendering of Atmospheres using Mie Theory both tackle rendering of the Martian atmosphere, by adding improved models for aerosol size and distribution (among other changes) to Bruneton's technique. This nets more accurate rendering of Earth's atmosphere as well, and somewhere along the way they even figured out how to render rainbows...

There also may be mileage to be had in stylised rendering, for applications that don't require photorealism. The only work I'm aware of in this direction is the aptly-named Aesthetically-Oriented Atmospheric Scattering.

See also

The Virtual Terrain Project is sadly defunct, but they have a pretty good overview of atmosphere rendering up through Bruneton's work.

Bruneton himself surveyed the major atmosphere rendering approaches as of 2017 in A Qualitative and Quantitative Evaluation of 8 Clear Sky Models

I have quit my job at Oculus, and immigrated to Spain.

External events have this habit of conspiring to throw your life into harsh focus. The first couple of months of Covid were relatively all right for me, I guess. I prefer working from home anyway. I don't mind entertaining myself at home. The next four months were a steady slide into monotony. Work and life blurring together until the passage of the days lose all meaning. Eat. Sleep. Work. Rinse and repeat. Lucky to be healthy and employed, but not feeling that way.

At the same time, the Brexit clock was rapidly counting down towards December 31st, and the moment when I lose my right to remain in the EU. I think it may be hard to grasp the significance of that from the outside, but EU citizenship is a privilege pretty much beyond comparison. The right to live and work in any of more than two dozen member countries, spanning a wide variety of languages, cultures, and climates. No visas, no work permits, no fuss.

So I sold what I could (which wasn't much, given the mass-exodus then underway in Seattle), hired someone to cart away the rest, terminated my lease, and flew over to Spain in October - before the winter lockdown closed that door forever. Met up with family on this side, so we could hunt for property here. And when the lockdown inevitably returned, rented an apartment to wait it out.

Spain is of course delightful, lockdown notwithstanding. Friendly people, excellent food, mild climate even up here in the north, and just a staggeringly low cost of living compared to urban America. After six weeks here my desire to go back to work under Covid conditions was just about at zero, so it was mildly fortuitous (albeit less so for my colleagues) when my team at work was on the receiving end of a fatal reorg - the day before I was scheduled to return. Followed shortly by the company deciding it wasn't ready to permanently allow remote work across international borders anyway. So I handed in my notice, and from today I'll be taking a bit of a break from the corporate side of tech.

What's next for me? Waiting out the lockdown, finding a small farm to restore, planting some orchards, and maybe getting a little arts and crafts going on the side. All while sorting out the many bits and pieces of paperwork that accompany immigration.

After that, we'll see. I'd like to figure out a tech niche that doesn't involve working 9-5. Which may prove to be an interesting challenge, as someone who prefers specialising in obscure technical areas, and has almost exclusively worked on big corporate projects the last decade 🤷‍♀️

Enter the spirv-struct-layout crate. It's pretty straightforward - you define a rust struct, #[derive(SpirvLayout)] on it, and then later on you can invoke the check_spirv_layout(...) function with the SPIRV bytecode of your shader.

Let's say we start with the following buffer structure in GLSL:

layout(std430, binding = 0) buffer Uniforms {
  mat4 model_view;
  vec3 light_dir;
  vec4 position;
} buf;

If you spend a lot of time writing shaders, you may already have caught the problem we want to address here: the spec says vec4 must be aligned to 16 bytes, so the compiler is going to add 4 bytes of padding after light_dir to ensure that position is correctly aligned.

Let's go ahead and define a rust struct to match this GLSL type:

use spirv_struct_layout::{CheckSpirvStruct, SpirvLayout};

#[repr(C)]
#[derive(SpirvLayout)]
struct Uniforms {
    model_view: [f32; 16],
    light_dir: [f32; 3],
    position: [f32; 4],
}

And finally we can run the SPIRV layout check:

fn main() {
    let spirv = cast_clice_u8_to_u32!(include_bytes!("simple.frag.spv"));

    Uniforms::check_spirv_layout("buf", spirv);
}

And if all goes well, the program will exit with an error:

thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `80`,
 right: `76`: field position should have an offset of 80 bytes, but was 76 bytes', spirv_struct_layout/examples/simple/main.rs:20:5

Now that the disaster has been averted, you have a few ways to address the underlying issue.

• The most straightforward approach is to just never use vec3 in uniform buffers - the alignment rules in GLSL just don't work out nicely when interchanging with host types, and various older GLSL compilers implement them incorrectly regardless.
• You could also insert 4 bytes of padding on the rust side (i.e. insert a blank f32 member between), although unused struct members are somewhat unergonomic to deal with in rust.
• For this very simple example, you could also just switch the order of the last two entries in the struct - since the vec4 neatly fills up the entire 16 bytes required by the alignment.
• And lastly, you could build a Vec3 type in Rust and use #[repr(align(16))] to force the same alignment as GLSL uses (but note Rust will also expand the size of the struct to 16 bytes in this case, meaning that vec3 followed by a float will still end up with 4 bytes of padding between).

This crate is still a work in progress, so when you run into rough edges, please report them over on the github repo.

A couple of weeks ago I participated in a 48-hour game jam hosted by PlayFab here in Seattle, with fellow procedural planet veteran Alex Peterson, my good friend and composer Leo Langinger, and the fortunate last minute addition of artist Brent Rawls.

We were both surprised and excited to have won this game jam, especially given the number and quality of competing entries.

Our entry, the somewhat awkwardly-named Mad-scien-tile-ology, is a Unity-powered take on the classical 'match-3' game (a la Bejeweled or Candy Crush), with the addition of an all-consuming biological 'creep', which consumes the game board as the player attempts to match tiles in order to slow its inexorable progress:

What went right

• Separation of responsibilities
  We had what I can only describe as an optimal team composition for such a short development cycle. Leo was able to focus on composing the music with a little sound design on the side, while Brent concentrated on the artwork, Alex handled all of the UI programming, and I wrote the gameplay logic.
• Time management
  We hit the ground running, with an initial match-3 prototype playable early Saturday morning. Thereafter we went into planning mode, and white boarded the roadmap and scheduled checkpoints throughout the day for each deliverable and each integration point for assets. While the estimates weren't perfect, and we missed on a solid handful of items, the organisation helped us to hit 90% of what we set out to do, and still get 2 relatively decent nights of sleep during the competition.
• Building on Unity
  Alex and I have both played around with Unity in the past, but neither of us had never shipped a full game thereon. Unity represented a fantastic time savings over building a game from scratch, and the asset pipeline alone saved us hours in wiring up the animations and audio.
• Having an artist, and an unusual artstyle
  We hit on the idea of stop-motion papercraft before finding Brent, but honestly were it not for his efforts it would have been a disaster. Brent ran with the idea and produced visuals which are striking and unusual. The real-world textures of the paper, the bold colour palette and the stop-motion animations really help the game stand out from other games of this type.
• Having a composer, and an original score
  It's easy to underestimate the impact of music on a video game, and as one of the only teams with a professional composer, I think we had an advantage out of the gate. Leo composed original scores for the title screen, gameplay loop, and victory/loss conditions. The upbeat and detailed music really helps sell the 'mad science' theme, and between composing he was able to produce a full range of foley effects for gameplay events that really help to sell the action on screen.
• Playtesting, playtesting, playtesting
  We had a playable (if minimal) match-3 game from mid Saturday morning, and that allowed us to play test each new element as we added it. This can be a double-edged sword - when short on time, you can find yourself playing the game instead of implementing features, but it did give us a good idea of what did and didn't work in the context of the game, and allowed us to fit at least some balance tweaks into the time available.

What didn’t go so well

• Version control + Unity = not so good
  We are used to working with a variety of distributed version control systems, so at the start of the competition we threw everything into a git repository and went to town. Unfortunately, we quickly learned that Unity isn’t terribly well suited to git. While all the source files and assets are handled just fine, a great deal of the configuration and logical wiring is contained in the single main.scene file, and being a binary file, git only sees it as an opaque blob. After a couple of merges that resulted in having to rewire assets by hand, we had to fall back to editing separate scene files and copy/pasting to the main scene file before we merged.
• Time is the enemy
  48-hours is not a long time, and irrespective of our planning, time grew increasingly tight as the competition progressed. While we were able to finish the game to a point we were fairly happy with, a number of features fell to the wayside, most notably highscores. We had intended to implement online leaderboards using our host PlayFab’s SDK, but that work had to be deprioritised to make time to fix critical gameplay bugs, and eventually we ran out of time.
• Last-minute changes are not your friend
  This one largely follows from the last two points, but Alex and I both tweaked different elements right before we packaged the game for judging, and somewhere in our merge we managed to lose the explosion effect for the player’s super-meter, as well as drastically increasing the pace and difficulty of the game in the final build. Neither change badly affected our ability to demonstrate the game, but it’s a lesson learned to put the pencils down and focus on testing in the final hours.
• Always be prepared to talk
  Winning the contest came out of left field, and the surprise coupled with a general lack of sleep had us roughly ad libbing our acceptance, and the subsequent quotes for the organiser’s press release. While one wouldn’t assume to win any competition, it turns out to be worth putting a few minutes of thought into what you would say if you do. Even a couple of sentences helps smooth over that deer-in-the-headlights moment.

What’s next?

We’re working on getting some of the more egregious bugs fixed, but if you’re of a mind to see how it is all put together, the source code and unity project is available over on GitLab. I don’t have binaries available for download yet, but we’ll try and make it available in a playable form when we have a few more of the kinks worked out.

And I’d be remiss if I didn’t give a shout out to PlayFab, for hosting (and catering!) a fantastic game jam, and our fellow competitors, who build some truly amazing games. Here’s looking forward to next time.

When I received Google's email detailing the repositories I have ownership over, I found a number of University projects, some python sample code, an entry to a video game competition, my now-venerable python user interface library, and one more item which I had forgotten about: a collaboration some years back to build a video game.

Like most such ventures, the collaboration fell apart after a few short weeks, the project creator and I went our separate ways, and I never heard from him again. But now, with the code scheduled to be consigned to oblivion within a year, it seemed like a good time to reach out and formally put the repository to rest.

It was then that I realised just how easy it is to lose information forever. I have an email address for the project's creator, but it turned out to be a long-defunct hotmail account, in the name of the project, not the user. The handful of of emails we exchanged don't list a real name, and mining various websites I was only able to find a possible first name, as well as a location of Christmas Island - a place so obscure I doubt he actually lived there. Team collaboration was largely accomplished through a private forum, but the project's website is long gone, the contents of the forum with it. The domain is still registered, but through a registrar in China, which doesn't list an owner in their whois records.

Long story short, unless he happens to read this blog post, I'll probably never hear from 'star.anger@hotmail.com' again. And in the greater scheme of things, it doesn't really matter: the game was never made, what small quantity of code made it to the repository will never be reused, and I doubt there is clear ownership of the code and assets regardless. The principle of it all still rankles, though.

For however short a time, a group of individuals came together to build something ambitious. That endeavour is over, the fleeting sense of camaraderie long gone. All that remains is an untouched repository and the half-remembrance of an anonymous typist behind a presumably-distant keyboard.

Who knows? Perhaps the other team members have stayed in touch. All that I know is that it's all too easy to lose track of people and things in a world based entirely on ones and zeroes...

The distance function for this spiral is not particularly hard to derive, but the derivation isn't entirely straightforward, and it isn't documented anywhere else, so I thought I would share. I am only going to deal with logarithmic spirals centered on the origin, but the code is trivial to extend for spirals under translation.

Spirals are considerably more tractable in polar coordinates, so we start with the polar coordinate form of the logarithmic spiral equation:

\( r = ae^{b\Theta} \) (1)

Where (roughly) a controls the starting angle, and b controls how tightly the spiral is wound.

Since we are given an input point in x,y Cartesian form, we need to convert that to polar coordinates as well:

\( r_{target} = \sqrt{x^2 + y^2},; \Theta_{target} = atan(y/x) \)

Now, we can observe that the closest point on the spiral to our input point must be on the line running through our input point and the origin - draw the line on the graph above if you want to check for yourself. Since the logarithmic spiral passes through the same radius line every 360°, this means than the closest point must be at an angle of:

\( \Theta_{final} = \Theta_{target} + n *360^{\circ} \) (2)

Where n is a non-negative integer. We can combine (1) and (2), to arrive at an equation for r in terms of n:

\( r = ae^{b(\Theta_{target} + n*360^{\circ})} \) (3)

Which means we can find r if we know n. Unfortunately we don't know n, but we do know rtarget, which is an approximation for the value of r. We start by rearranging equation (3) in terms of n:

\( n = \frac{\frac{ln(\frac{r}{a})}{b} - \Theta_{target}}{360^{\circ}} \) (4)

Now, feeding in the value of rtarget for r will give us an approximate value for n. This approximation will be a real (float, if you prefer), and we can observe from the graph above that the closest point must be at either the next larger or smaller integer value of n.

If we take the floor and ceil of our approximation for n, we will have both integer quantities, and can feed each value back into equation (3) to determine the two possible values of r, r1 and r2. The final step involves finding which of these is the closest, and the distance thereof:

\( min(|r_1-r|, |r_2-r|) \)

And there you have it:

The python source code below produces the image shown above, as a 1000x1000 pixel image PNM image written to stdout. If you aren't familiar with the PNM format, it is an exceedingly simple ascii-based analogue of a bitmap image, and can be loaded directly in GIMP.

import math

def spiral(x, y, a=1.0, b=1.0):
  # calculate the target radius and theta
  r = math.sqrt(x*x + y*y)
  t = math.atan2(y, x)

  # early exit if the point requested is the origin itself
  # to avoid taking the logarithm of zero in the next step
  if (r == 0):
    return 0

  # calculate the floating point approximation for n
  n = (math.log(r/a)/b - t)/(2.0*math.pi)

  # find the two possible radii for the closest point
  upper_r = a * math.pow(math.e, b * (t + 2.0*math.pi*math.ceil(n)))
  lower_r = a * math.pow(math.e, b * (t + 2.0*math.pi*math.floor(n)))

  # return the minimum distance to the target point
  return min(abs(upper_r - r), abs(r - lower_r))

# produce a PNM image of the result
if __name__ == '__main__':
  print 'P2'
  print '# distance field image for spiral'
  print '1000 1000'
  print '255'
  for i in range(-500, 500):
    for j in range(-500, 500):
      print '%3d' % min( 255, int(spiral(i, j, 1.0, 0.5)) ),
    print

You can probably guess the next stage of this anecdote... Office '98 on that G3 performed ever-so-slightly worse than Office 4.0 on a truly ancient PowerBook 180, which sported a fantastic (for the time) 33 MHz Motorola 68030 CPU.

Now, I am not being entirely fair here - the spellchecker is much faster, the grammar checker didn't even exist back then, the user interface only had to render at a 1024x768 resolution in those days, and various other ancillary features have been added and improved. But the core issue remains, Office 2010 (or 2007, which is not in beta) running on a decent gaming PC, takes longer to launch and is less responsive to keyboard input than Office 4.0 on an 33 MHz 68k.

And the problem isn't restricted to Microsoft products alone, as many pieces of software have suffered the same sort of creep, not least among them the Mac and Windows operating systems.

In the open-source world and among smaller developers this phenomenon is far less common: a well configured linux or BSD installation boots in a handful of seconds, Blender (sporting most of the features of expensive software such as 3DS Max and Maya) launches immediately and always remains responsive, and Maxis' Spore takes minutes to start up and load a game while Eskil's Love throws you into the game in under 10 seconds.

My current computer is many thousands of times faster than that PowerBook 180, so in theory at least, we should be able to do far more, and do the same old things much faster. Why then the slowdown?

It can't be lack of resources - we are talking about companies such as Microsoft, Apple and Adobe, all with enormous R&D and development budgets, and teams of experienced programmers and engineers. Besides, the open-source guys manage just fine, some with just a handful of programmers, and most with no budget whatsoever.

It has been argued that programmer laziness (a.k.a. badly educated programmers) is to blame, but I am not sure this can be the entire story. Certainly the 'dumbing down' of University-taught computer science hasn't helped, nor has the widespread rise of languages that 'protect' the programmer from the hardware, nor the rise of programming paradigms that seek to abstract away from low-level knowledge. But that is the topic of another rant, and is somewhat tangential to the topic at hand. Companies can afford to hire the best programmers, and could if they wanted to, create the demand necessary to reform education practices.

And that brings us to the real heart of the issue: software developers measure success in terms of sales and profit. As long as your software sells, there is no need to spend money on making the software perform better. And if you happen to have a virtual monopoly, such as Microsoft's Office or Adobe's Photoshop, then there is no incentive to improve the customer's experience, beyond what is needed to sell them a new version each year.

However, when you lose such a monopoly, the game changes, and it generally changes for the better. When FireFox, Opera and later Safari started cutting a swathe into Microsoft's Internet Explorer monopoly, Microsoft was forced to adapt. The latest version of Internet Explorer is fast, standards compliant, and relatively free of the virus infection risks that plagued earlier versions.

This outcome of the browser war has led at least a few to the conclusion that open-source is the answer, and that open-source will inevitably recreate what has been developed commercially, and either surpass that commercial product, or force it to evolve. Sadly, I don't see this happening particularly quickly, or on a wide scale - OpenOffice is playing catch-up in its efforts to provide an out-of-the-box replacement for Microsoft Office, GIMP lags far behind Photoshop, and linux, despite widespread adoption in a few key fields (namely budget servers and embedded devices) still lags far behind Windows and Mac in many areas.

For many years this wasn't a problem - every few years you would buy a new computer, typically an order of magnitude faster than the computer it replaced. If new versions of your software consumed a few million more cycles, well, there were cycles to burn, and besides, the hardware companies needed a market for faster computers, didn't they?

Nowadays the pendulum is swinging in the opposite direction. Atom powered netbooks, Tegra powered tablets, ARM powered smartphones - all of these promise a full computing experience in tiny packages with minimal power consumption. Even though the iPhone in your hand is considerably more powerful than that 33 MHz PowerBook 180, it doesn't have even a fraction of the computing power offered by your shiny new laptop or desktop. And users expect a lot more than they did in the early nineties - animated full colour user interfaces, high definition streaming video and flash applications, oh, and don't drain the battery!

CPU cycles today are becoming as precious as they ever were, only now many of our programmers have no experience of squeezing every last drop of performance out of them. Has the business of software development come full circle, and once again become the territory of the elite 'low-level' programmer?

Part of the rationale behind this video is to streamline the whole video capture and posting process. Unfortunately, it hasn’t been entirely straightforward so far. I went through a number of video capture tools before settling on FRAPS, which works well enough (though I would have prefered a free tool).

I also have had a terrible time converting the video for youtube – ATI’s Avivo video converter is blazingly fast, but apparently produces an incompatibe audio codec in any of the high-quality settings. I was forced to fall back to the CPU-based Auto Gordian Knot, which both does a worse job, is very slow on my little Athalon 64 x2.

I am now experimenting with ffmpeg, but the command line options are confusing to say the least. If anyone has any clues/tips/tricks for getting FRAPS encoded video (and audio) into a suitable format for youtube HD, please let me know.

The semester is over at last, and my grades should be in by Monday. It has been a tiring semester, but not a bad one, with interesting courses in database implementation and parallel architectures, not to mention philosophy.

With the end of the semester comes a little more free time, and I have spent a chunk of it recreating my old procedural planet demo in Python/Pyglet.

The first big plus is that whereas my previous implementation was over 5,000 lines of C++ code, the python version is under 1,000 loc, plus a few hundred lines of tightly optimised C for the tile generation back end.

The other plus is that this version actually works. I finally found the time to fully implement the crack fixing algorithm, and the results are very good (although there are still a couple of unresolved edge cases).

I also implemented normal map generation in GLSL, to offload the computation to the GPU. This more than doubles the performance of tile generation, to the point where several tiles can be subdivided or combined each frame.

From a technical standpoint, the planet starts as a cube, and each face is subdivided to form a quad tree. For each tile at the deepest level of the quad tree, a small heightmap is generated using 32 octaves of 3-dimensional simplex noise. This heightmap is used to generate the vertices for the tile, and passed as a texture to the GPU in order to generate the normal map.

Because applying tangent-space normal maps to a sphere is an absolute nightmare, I take the unusual approach of generating object-space normal maps. These are considerably more expensive to generate, but avoid the tangent-space mismatch at cube edges, and look fairly decent in practice.

Interestingly, this version allows one to fly right down to the planet surface, and maintains interactive framerates even on my Intel integrated X3100 (complete with the awful Mac drivers). By the time I add atmosphere shaders and detail textures, I expect that I will have to switch over to my desktop, but for now, I am very happy with the performance.

Of course, there are still several challenges to overcome, in particular the issue of depth buffer precision. The planet you see above does not suffer from a lack of depth buffer precision, but it is only 1/10 scale of the Earth, and ideally I would like to be able to render gas giants on the order of Jupiter as well. This requires some clever on-the-fly adjustment of the camera frustum, and I don’t quite have a handle on the best way to accomplish it.

I haven’t had much time to update here in a while, having been hard at work on an entry for the udevgames contest. If you read my earlier post, you may recall I was initially going to enter a pixel-art lemmings clone, but midway through development, I decided that the concept was basically not fun to play.

So I switched over to building a 3D space-sim, with only a single month remaining in the competition. The plus side was that I have much more experience with 3D graphics, but lack of time was still a killer. I can’t honestly say it is much more fun to play, given its unfinished state, but the core gameplay is certainly there.

The game is basically a prototype, and an example of a larger game produced with Python and Pyglet. As per the rules of the competition, the game is open source, although in its present state, it probably isn’t much use to anyone. When I have the time, I intend to cleanup and comment the code, which will hopefully be useful to others starting out with Python, Pyglet, or games development in general.

Despite the code being cross-platform, I only have a Mac binary up for now, as I have unable to coerce ODE into even a semblance of stability under Windows. When or if I manage to sort the crashes out, it will run fine on both platforms.

So if you have a Mac, and want to take the binary out for a spin, you can grab it from http://www.udevgames.com/games/entry/ashima_iv, or if you would like to browse the source, visit the project page at https://github.com/swiftcoder/ashima-iv. While you are about it, consider taking the time to check out the other entries to this year’s udevgames contest, and remember to vote for your favourites!

Spending a little time on the visualisation side of things at the moment. At right you can see the result of rendering the previous images as a height map. A simple colour map is applied based on elevation, and the terrain is lit.

The terrain is fairly low resolution, only 128×128 vertices, while the height map is 1024×1024 pixels. To increase the quality of the lighting, a normal map is generated from the height map, also at 1024×1024 pixels. This yields 8:1 vertex to texel ratio, giving very decent performance while still rendering at a high quality.

The terrain is actually split into 4 equal sized patches, 64×64 vertices each, in order to aid culling. At some point I will improve this system into an adaptive quadtree, which should provide far better performance.

I am rendering this all on an Intel integrated X3100 graphics processor, and so far I have been very impressed with the performance. Despite running commercial games extremely badly, this card seems to take no performance hit when using shaders instead of fixed function rendering, and in fact, the current shader-based normal mapping is faster than the previous fixed-function lighting.

After using a mixture of voronoi and simplex noise to generate a height map, I realised that it doesn’t look very good – in particular the noise generation creates hard edges and jagged formations everywhere.

The solution to this is, or course, erosion. At right you can see the results of applying a very simple approximation of thermal erosion to generated height map.

This implementation is an image space post process. For each pixel, a fixed height is subtracted, and the algorithm then travels downhill, until it either reaches a maximum distance, or finds no adjacent pixel lower than the current pixel, at which point it deposits (adds) the same fixed height.

The images at right were generated by applying ten repetitions of this filter, for various values of the distance parameter. As you can see, larger distances tend to preserve detail on slopes, and result in large flat areas. Smaller values smooth out slopes as well, but don’t greatly affect the overall shape of the terrain.

This looks pretty good for a first stab at erosion, and is very fast, but I expect that a full implementation of thermal and hydraulic erosion will look substantially better.

Yesterday I set about generating 3D noise, in particular, texture maps for 3D planets. It sounds like a relatively straightforward extension of 2D noise, but unfortunately it didn't turn out that way.

First up, a SphereMapper generator. This handy little class takes a 2D coordinate, and transforms it into a 3D coordinate on the surface of a sphere, just basic Polar to Cartesian conversion. Of course, this generates 3D coordinates on a unit sphere, and while the front looked all right, the back looked absolutely terrible.

Turns out my Voronoi implementation didn't work correctly with negative coordinates. This required only a simple fix, but unfortunately that fix required axing the optional tiling qualities I had added in the day before.

Then it also turned out that my Simplex implementation didn't work with negative coordinates either. I haven't figured out a fix for this yet, so in the meantime, I have implemented a version of Value Noise (as described by Hugo Elias). This is a fairly decent approximation of Perlin/Simplex noise, and does work with negative coordinates, but the quality is a little worse, and the high quality version is considerably more expensive than simplex noise.

I will have to fix the simplex noise at some point, but in the meantime, value noise is a good generator to have, and it makes for pretty decent looking planets.

I also notice that my OpenGL sphere class has a lot of texture distortion in the polar regions - far more than should be expected. Apparently generating a sphere out of stacks and slices isn't as straight forward as one would imagine...

Shortly after my last post, I realised my Voronoi basis had a problem: only the distance was taken into account for each cell. This has been corrected, with each cell now assigned a random base value, to which the distance is added.

At the same time, I noticed that the voronoi basis wasn't much use on its own - polygons are an unusual shape in nature. This lead to the addition of a Turbulence module, which perturbs the input coordinates according to another generator.

Together these additions allow for some striking images, and adding these to a few octaves of simplex noise lends itself well to terrain - the bottom image makes for a quite convincing height map, though improvements can obviously still be made.

I am also testing the inclusion of an additional diamond-square generation technique, but it doesn't play very well with other approaches. Unfortunately, diamond-square generation can only be used for square images with power-of-two dimensions, must be generated an entire image at a time (which pretty much precludes mixing it with other noise types), and only works with basis generators which have a gaussian distribution (i.e. not voronoi). Diamond-square does however offer very fast generation, so I think it will be included in the library - specifically for those applications that need extremely fast generation of fBm-like textures.

I recently moved all my graphics and games development over to Python, using Pyglet. Overall this has been a very good change, with a great increase in productivity, but unfortunately it has caused a few problems.

Previously, I had been using libnoise for all procedural generation, but it turns out that Pyglet is implemented using ctypes, while the only available python bindings for libnoise were generated using SWIG.

Naturally, the developer's of ctypes and SWIG never made basic pointers compatible (nor with boost::python), so it turns out that there is no way to load a libnoise generated image into a Pyglet/OpenGL texture.

I haven't been entirely happy with libnoise for sometime (primarily because of difficulties tiling voronoi noise), so this gives me the perfect excuse to dive in and implement my own noise library.

The library is developed in C++ (for efficiency), and has an external interface written in C, to easily interface with Python (using ctypes). At this stage the entire library is contained in a single source file, and weighs in at just under 500 lines of code.

The code itself is flexible and extensible: You create one or more Generators (which can each combine other Generators), and a Renderer, and feed both to a Generate function.

The image above was generated by a python script, and shows off all the current features of the library. Two generators are provided (simplex noise and voronoi), which can be combined into octaves (fractal-brownian motion), and blended together (weighted addition). The image can then be rendered in greyscale (such as for a heightmap), or rendered with a colour palette (as in the lower left image), and in either unsigned byte or float precision.

I hope to add several generators, in particular more blending functions, in the coming weeks. After that, with a little code cleanup, I think an open-source google code release is likely.