Multiresolution Progress Update

A lot of my focus has been on bugfix/development issues lately, but support for Multires (and some other goodies) is coming along steadily.

Things are mostly complete — just lots of edge cases to fish out and fix where WM previously made some assumptions that the output resolution would always be the specified world resolution.

Here’s an example of a modified starting world, where the terrain has been downsized to quarter size (129×129), and the texture has been upsized 4x (2049) with fractal noise added. The Overlay View works seamlessly with these differently-sized inputs:

Multiresolution World

Note how the lighting and geometry is very low-res and smooth, while the texture is still high res. This is definitely not the worlds’ best example scene, but it shows generally how you would work in this environment.

I was afraid that this extra element of control would lead to counter-intuitive editing, but its mostly understandable and controllable. I think this is because of the following rules that WM uses:

  1. Devices operate on whatever resolution their inputs are seamlessly.
  2. If a device has two or more inputs of different resolutions, the smaller one is upscaled to match the larger (unless the device has flagged some of its inputs as allowing mismatched resolutions, like the Overlay View does)
  3. “Resolution Change Points” are marked in the device graph. (Note the grey resolution report under the Clamp and Select Convexity Devices).
  4. You can specify a resolution either as relative to the World setting, or a fixed value. There are good uses for both of these. In particular, if you are trying to create coarse geometry then upsample later in the network, a fixed resolution works much better — its disconcerting to have the geometry resolution change when you change the final output res.

The final bits of work required are making Layout View happy with the changes, and some final UI tweaking.

There are some additional enhancements I wanted to do, like allowing per-group resolution settings rather than just per-device, but that one will hold off a bit until some later changes to groups that makes them a bit more of a full-privledge member of the device world…


Lastly, there are some other improvements that will be rolling out at about the same time. One of them is the topic of the next blog post…



Progress Update

Just a quick update to mention that work is proceeding, although the feature branch is slightly lagging as more time has been put the last few weeks into another bugfix release which will be out shortly.

I’ve also been investigating some intriguing new devices that would provide additional terrain shaping abilities. Too early to talk much about that yet, but if they continue to show promise it might make an appearance sooner than later.

Anyways, what’s in place for the multires support:

Resampling method support has been added to the file input and tiled file input devices, and a generic set-resolution dialog implemented for all devices. What remains UI-wise is deciding on a way to clearly denote the resolution state of different devices in the world. There’s also some issues to track down with multires, particularly in layout view and with regards to macros.


Feature Branch #1

I mentioned the other day that I would be posting more information about development direction soon. That post is still yet to come, but I thought I would start talking about what kind of features are being worked on for inclusion within World Machine in the relatively immediate future.

So here’s the first in the series!

Different Resolution Support

The current feature-in-development is the ability to have different sections of the device graph operate at different resolutions in the same world file. How does it work?

The basic rule of thumb is that you can set any device to operate at a fraction or multiple of the resolution set in the world file; That section of the graph will then flow at the new resolution until encountering device(s) that change the resolution again. If two different resolutions meet at a device, the lower-res one is upscaled to match the higher one. This allows existing devices to more or less ‘just work’ without requiring me to change anything.

Why would you want this?

This is very powerful and handy; you can do anything ranging from simply setting the resolution of your outputs independently (for example, for your heights vs normal maps vs bitmaps), all the way to having lots of different effects that are processed at different resolutions. For example, your high-resolution builds could run with most of the world-building done at a more modest resolution, then upsampling right before final detailing and output, saving lots of memory and time.


Of course, having different resolutions all over the place requires improved support for re-sampling the resolutions of heightfields when needed. WM has always just done bilinear interpolation when required, which is the bare minimum but leaves a lot to be desired. I’ve just finished adding support for new resampling abilities, as seen in the graphic below.

Upsampling from a 64×64 source to a 512×512 heightfield in WM:


These will be the resampling filters implemented in the next feature release. Let’s go through them:

  1. Nearest Neighbor: This is not too useful for heightfields except if you’re going for a minecraft-look. However, this can be very useful for bitmaps as a method when dealing with material maps/atlases where each color actually is a code for a particular type of coverage; In this case blending doesn’t make any sense.
  2. Bilinear is what we’re used to. When applied to heightfields lots of creasing artifacts are in evidence, although in some cases this sharp look is very useful.
  3. Bicubic: (Soft) uses an approximating B-spline to create a smooth, C2 continuous surface. This is a great choice when you need to produce a very smooth output terrain, and will probably be the new default choice.
  4. Bicubic (Tuneable): This choice provides you with a “sharpness” tuning parameter, which ranges from the same as Cubic-Soft to quite sharp. This is immensely useful for images as well as heightmaps… As a ‘season-to-taste’ parameter, the correct value is according to your artistic judgement. For fellow math geeks, these are the Mitchell-Netravali spline family.
  5. Fractal: This adds fractal detail to the interpolated surface adding rougher details in high-variance areas. This is a simple and basic way to add some detail to a low-resolution input, and is easier than manually setting up the equivalent network in World Machine itself. It is tuned with a single roughness parameter. High roughness is also useful for things like material maps, which tend to get too blurry when upsampled from low resolutions. I’m still fine-tuning the algorithm here for best results, but the intention is to be a fast’n’easy solution, not the ultimate fractal upsizer; The Advanced Perlin device is the best bet for that, especially with some tweaks being made to improve the ability to quickly setup that device for detail-adding.
  6. I can’t resist a final image of the fractal resample with some erosion and texturing added!

I also experimented with some other ‘designer’ resampling kernels like Lanczos, but decided that they didn’t bring anything to the table that wasn’t already covered by the above.

All of these will be presented as options both for resampling within WM, and when importing from a regular or tiled file input.

What’s left to do

A fair bit:

The major work remaining on resolution/resampling support lies with the User Interface. The workview should mark all devices that are at non-default resolutions so that you can at-a-glance see where your custom settings are. Ideally the controls for setting the resolution (as well as a few other things as I will detail in upcoming posts) would reside directly within the dialog box for the device, but due to framework issues this is a mammoth task what with all of the custom device dialogs in WM. Instead, these are currently accessed through the right click context menu.

In addition, all of the various views and features (layout view / tiled builds / etc) that expected consistent resolutions will need to be modified to work within the new system.

Finally, the file inputs need to be modified to provide the additional options.

Final Thoughts

The update containing this ability should become available within the next month. I picked this as the first new post-2.3 feature to add as it is both highly requested and doesn’t require extensive R&D to implement. Have other things you’d like to see? Post about them on the forums!


The Taste of Progress

Yesterday I released 2.3.3, which marks the third revision to WM since the 2.3 release… which itself occurred only 2 months ago. 

I’m very satisfied with the new pace of progress! There are many reasons for it, a few of which I will detail below. But more than anything else, this characterizes how I really would like to develop World Machine — relatively frequent releases that bring new abilities and fix issues.

I’ve always been frustrated by the lengthy and slow release cycle that WM suffered from before. It’s not good for anyone to have the fixes for issues languishing for months or years(!) while the product is still in a beta phase before release. I think that 2.3 marked the end of the traditional development model for WM — more details to come.

The next section talks a little bit about what I’ve been able to change post-2.3 to make development faster. 

Development Details:

What did I change to be able to iterate versions much quicker? A few things:

  1. I changed to Mercurial for source control. The ability to branch and merge effortlessly has allowed me to keep feature and release branches seperate, something that was always far tougher than it should have been using the old style SVN (or nothing!).
  2. I automated much of the build process, so that kicking out a new version to the website takes maybe a half hour rather than most of a day.

Not a lot of differences, but enough to remove the friction from the process and make it easy to get changes out rapidly.

World Machine 2.3 Released

Its time!

World Machine 2.3 Final is now released. 2.3 is now available on the upgrade site at

There are some seriously awesome improvements and compelling new features, not to mention a whole slew of bugfixes.

On the flip side, perhaps sometime soon I will post a postmortem on 2.3 — on the whole it took far, far too long to get it put out the door. The extended development cycle was hard on me, and hard on the users waiting for bug fixes! I continually forgot that new users not part of the public beta were using a version (2.2) that was out of date and contained bugs that I fixed long ago.

One of my goals moving forward is to change to a far more frequent release cycle; bugfix releases should come as fixes happen, perhaps monthly; the plan for large feature releases deserves its own post and will get it.

In any case  I mentioned earlier, there will definitely be time for reflection soon. But for now, I hope you enjoy the changes: The very-soon-to-be-updated website has an extensive list of them. It really is not hyperbole at all to say that some of them will quite change how you create your World Machine worlds.



Improving Real World Data

I wanted to talk briefly about a very popular but often unmentioned use of World Machine: Taking low resolution real world DEM files and creating something with more detail suitable for use in art or simulation.

This is one of the areas that I think could definitely use a tutorial! For an example of the power of the transformation, here’s a quick look at a before and after of a low-resolution DEM of an area of Washington state in the USA:

Before and After


Click on the above to blow it up. Specifically, note how we’ve carefully added artificial detail that complements the quite coarse real-world data we have to work with. Hopefully I will get a chance to make a walkthrough soon.. but here’s the network for the world above:


World Machine 2.3 Ready for Christmas?

Hi folks,

Just wanted to mention that code changes are essentially complete for 2.3. I was originally hoping to have it released by Christmas time, but it looks like it will slip that a little bit.

Mostly, because I am trying to include some additional resources such as new macros and example files. Many of these reflect common questions or scenarios addressed on the forums over the years, so I figure it makes sense to make these available to everyone included in the default distribution.

For example, here’s an image from a newly included example file demonstrating how to create a volcano:


The example above demonstrates how to place a single “hero” mountain onto the terrain, as well as punching a crater into the top of it and simulating lava flow with the snow device.

Merry Christmas to all!

June Update

So, what’s been percolating behind the scenes in the past while with World Machine?

Mostly things like bugfixing, business-side, and other custom work. I believe that 2.3 Beta-3 is starting to achieve very solid status; there are only a few more things I want to get into line before final release.

I’m writing here, however, about a new feature. Even though I’ve sworn to myself to feature-freeze 2.3, I find that the allure of working on a few small things from the feature-request backlog sometimes gets to be too much. Which explains the reason for this post…

Take a look at this screen capture straight out of World Machine:

There’s nothing obviously strange about this image, but it’s showing off a couple very cool new features that, despite being small, will revolutionize the way people texture with World Machine.

In particular, this image is using the new Colorizer tool to create custom textures. The existing Colorizer was only ever meant to simply allow you to use the built-in colortables in your texturing schemes. That can be useful, but is of only limited power.

The new colorizer allows you to quickly create custom RGB gradients. But far from simply using them as a height-color lookup table, in my experiments so far I’ve found them to be indispensible for practically every texturing purpose. Any time you want to vary color based on a heightfield, the new colorizer is now your go-to tool. Whether that means a gradient based on height, slope, erosion status, or practically anything else — being able to quickly map your input to a custom set of colors is huge.

In particular, in the image above I created a rough grassy pattern using a couple noise devices, then drove a colorizer with it to get a nice mottled grasslands color set. I did the same thing for the dirty areas, then Choose between the two based on slope/erosion data.

One other last interesting trick:  You may notice there’s alot of “rough” feel to the surface; I plugged a small collection of nodes together to effectively combine the texture with a surface texture heightmap and bake the resulting light+bump map into the surface texture. This is a cheap, but fun, hack.


To Crash, or not to Crash..

Hi folks,

I just realized that its been a while since I last posted here, so I figured I had best make an  update!

There’s been lots of work being done but not much visible progress lately. Partially this is because I’ve been doing a fair bit of work not directly related to the main  World Machine codebase  lately. However, more important is the fact that I’ve been doing lots of work in the last few months or so in improving the error handling of World Machine.

WM never really has handled error conditions particularly well; your answer to asking to do something beyond its capabilities was almost always a crash. The crash reporting handler in the last beta was the first step in refining things. For this next beta, enormous amounts of work have been put in to make World Machine maintain stability, recover gracefully, and inform you properly when things don’t go according to plan. This is particularly true of memory handling; My goal for the next beta is that you will be unable to make WM crash no matter what you ask of it! (Whether this is achieved will remain to be seen..)

News, Ideas, and Random Musings by the author of World Machine