All posts by Remnant

World Machine Author

Build 3017

Build 3017 is now live on the Dev Channel, with the full changelog posted on the update center.

The primary focus of this release was continued improvements to the River device, with special focus on making the UI and controls more intuitive to use. Although still certainly not perfect, this release is a major step forward.

Of course, there are several additional very useful changes in 3017, including the life-saving “Estimate build time” command in the World Setup dialog, but the focus was on the River device.

The first thing you’ll notice is that the rivers are displayed more intuitively; the flow direction is indicated by chevrons on the path, including marching flow direction if you don’t have a GCS overlay selected.


And although it’s hard to show in a static image, the behavior and defaults are now much closer to what an artist might expect, while still preserving the specificity that was possible before.

For example, if you just take the default WM world, drop a river device onto the output of the noise generator, and then click “Add Reach” within the river device and sketch a river, you’ll get this:

Which may not be especially pretty, but is probably a much closer match to what you were hoping to produce than the previous versions!

The main things that have been improved are:

  1. General UI behavior and display
  2. Elevations can now be manipulated much more easily: You can still manually specify a datum and slope as before, but you can also have the reach elevations be set automatically from the terrain (the new default). The river will be placed below the terrain elevation a distance specified by the valley height
  3. The reach valley walls are now improved and include both a fractal breakup and also control of the valley shape, allowing you to achieve both U and V shaped valleys.
  4. The behavior of child reaches is improved, both in the display blending between them and also the way they get their elevations from both the terrain and their parent.

There are still some issues with the River device, and it is currently flagged “Experimental” within WM, a new status for 3017 and beyond. Experimental devices are those that have notable issues that remain to be resolved, or expect to have their interface changed, but are too powerful to let them not be included.

I’ll end with a larger view at one of the new example files included, modeled very loosely after the Grand Canyon area. What’s awesome is that if you play with this example, you can easily add tributaries and extend the river with almost no additional work, while getting results like the below:
I don’t know about you, but that’s pretty compelling to me!

Lastly, I wanted to mention that this release is also going to lead into a major milestone — All of the features of the Dev build are going to be synced to the Release build soon.

Compared to WM 2.3.7, The current dev build is incredibly feature rich and advanced by this point. It was never intended to get quite so far ahead in the first place.  A variety of circumstances conspired including an unclear conception and policy on my part on deciding how perfect a feature needed to be to be Release-channel-worthy.

The result, among others, has been that new users of World Machine have been completely kept in the dark about all of the advancements over the last several years until they by chance read about or try the Dev channel.

There’s a lot more I could say about updating the release channel but I’ll keep this short for now. Briefly, the next steps  are going through reviewing, packaging, and revising examples, macros, and blueprints for all of the new features in preparation for updating the Release channel (including the Basic Edition). This shouldn’t take long.. keep your eyes peeled in the immediate future!

Build 3016

Hi folks,

Build 3016 is almost ready to go. I’ve been trying to rotate areas that get attention with each release, in an effort to evenly hit various pain points, requested new features, and features that you didn’t know you needed until you seen em. 😉 There’s still a lot of exciting things to come regarding rivers, texturing, new erosion models, etc, but I wanted to address a few other areas with this build.

One underlying goal is to be able to move the Dev channel build over to Release channel soon. Thus, a number of the changes are aimed at enabling you to create good results faster and with a better experience. Without further ado, here’s what’s new, improved, and changed, large and small:



Blueprints are a snippet of connected devices that you can quickly paste into your world. The intention is to speed development of common tasks of world creation, while still keeping all of the various parts visible and tweak-able at will.

This contrasts with macros, which intentionally hide their contents away and present themselves as an abstract, black box. This goal is complementary to Blueprints, which can make connecting and setting up your macros quicker and easier.

The uses are many, but especially:  Rapid creation of your world by dropping prefabricated “bricks”,  quickly placing sets of commonly used-together devices, standard file I/O blueprint for your project’s needs (directory structure, what to export, low and high res exports, etc), etc etc.

Blueprint files are simply TMDs stored within the Documents\Blueprints library folder, so they are easy for you to edit and share. You can create them either by saving worlds into the Blueprints folder, or using the handy drag-and-save blueprint creation tool within WM:

3016 will ship with some basic blueprints, but this is definitely an area where you will hopefully find  yourself quickly creating a custom set of blueprints, as the bar to creation a useful blueprint is intentionally much lower than macros.

New Library Interface



Build 3016 promotes both Macros and Blueprints to the same level as devices: Any favorite macro/blueprints are now available in the menubar as well as the right-click context menu. The improved library dialog fixes a regression where favorites were not being saved or handled properly, and now allows you to mark an entire folder as a favorite as well.

New Examples


The “Load Example World” command now also uses the library dialog, making it easier to browse the library of example files.

The library of how-to files and scenes  is being revised and fleshed out with an eye towards the next build becoming the standard Release channel build that is downloaded by new users.

I’m experimenting with making the Load Examples function more visible by promoting it to the menubar. This may or may not persist, but I want to make browsing and experimenting with examples as easy as possible for new users.


Several very important bugs have been fixed in this version, including finally tracking down a crash & build problem that has lingered in the dev builds for quite a while revolving around state corruption after undo/redo, device deletion, etc.  And in case you still run into a crash bug, World Machine now has:


The current state of your world is kept saved at all times; if World Machine crashes or your machine otherwise has an interruption, WM can reload your work on its next start.  This has been unexpectedly helpful to me during the development of WM itself, and it should continue to be useful to ya’ll in the field.

Copy/paste between instances

You can now copy/paste between multiple running instances of WM, as WM now uses the windows clipboard rather than its previous internal one. This may also prove useful for 3rd party utility authors, as the clipboard format used is simply the WM file format.

Misc small changes

  • Deleting a group now deletes all of its contents, including other groups
  • Instance scatter bugfix so that its placement mask does not move with the device origin
  • Checkpoint device ports can now be named by the user

Basic Perlin revamped

The Basic Perlin device was previously a “vestigial” device, as it was simply the older fractal noise generator and wasn’t necessarily simpler or easier to use than the Advanced Perlin that replaced it.

There’s now a reason for it to exist : going forward, Basic Perlin can/will be your go-to device for simple noise, reserving the Advanced Perlin device for when you needs its more sophisticated tools (multifractals, guide maps, custom fractals, etc).

Basic Perlin has been both simplified and had some very much needed improvements like output elevation controls (including an option to specify the typical slope of the output instead of the height range).

Advanced Perlin and Voronoi will in the future also receive a number of updates soon as all of the primitive devices get a once-over, but  that will have to wait until build 3017…

Roughness Selector

Saving the best for last, perhaps one of the most transformative features is the new Roughness Selector, which promises to almost certainly find its way into your texturing schemes.

The Roughness Selector is a natural, powerful complement to height, slope, and erosion mask-based texturing. In a nutshell, it does what it says : Produce a mask that indicates what areas of your terrain are rough, and what areas are smooth.

Roughness Selector Output

So simple, and yet — I’ve already found the Roughness Selector useful enough to rethink my entire basic texturing scheme, and I’m sure you will discover even more uses!

The Roughness Selector produces output that cannot be achieved by the Slope and/or Convexity Selector, as seen below. In this comparison, each selector is simply fed into a Colorizer to texture the terrain based upon its action. The roughness selector picks out rocky areas while leaving smooth meadows alone, even if they are steeply sloping.

Slope-based on top, Roughness-based on bottom


This seemingly simple device was actually much harder to tune than expected, as many of the methods you might think of to identify roughness (such as std deviation of elevation or slopes, for example), don’t produce aesthetically pleasing output or are too highly correlated with the terrain slope to be useful. The output mask can range from smooth to relatively “noisy”, which is actually very useful as the noise is correlated to terrain features and looks good, much like the erosion masks.

As hinted previously, one perfect use case is identifying areas of the terrain that contain rock vs soil. There are many natural locations that will have smooth but steep soil-mantled terrain right next to jagged rocky cliffs — we can now analyze our terrain for these and treat them differently.

Color by roughness — smooth hillsides interpreted as vegetation, rough hillsides as rock

This is pretty much as good as it gets right now, short of a full scale soil evolution model. Ahem. 😉

This is a masking/texturing primitive that I’ve always wanted to have available, so I’m very happy it is finally making an appearance. Individually or in concert with the existing selectors, you will find it a very powerful tool for texturing.


That’s it for now! Build 3016 should come out next week, and Build 3017 should follow along a little ways after that. Cheers

Build 3015

Hi folks,

Build 3015 has been released! Besides fixing some bugs, and a few smaller tweaks, the primary focus is improving a device I’ve never been completely happy with: the Thermal Weathering device.

The old version of Thermal Weathering had its uses, particularly in concert with the erosion device to help shape the sometimes over-steep slopes produced. However it never fully achieved its primary goal: to simulate the way freeze/thaw cycles break down rock faces and produce talus slopes.

I’m happy to say that the new version excels at that task!

Let’s take a quick look.  This is one of the example files included with Build 3015. Here’s a  canyon-type terrain:

Standard Erosion Only

Right off the bat, we can see that this is not a situation where WM’s erosion model traditionally excels. None of the natural forces that would dominate in this situation are being simulated, leading to a result that doesn’t look realistic. Among the problems are the lack of debris at the base of the cliffs, unrealistic streamlines down the cliff faces, and more.

So let’s try to fix it, using classic World Machine 2 Thermal Weathering:

Old Style Thermal

In some ways this is an improvement, but in others, a step backwards. Talus and other debris have begun accumulating on the slopes, but not in a consistent way or in a location that is actually where you would expect. This is due to a variety of reasons I won’t go into here, but the short version is that we still don’t get our talus slopes.

What’s worse, all of the nice erosional detail in the rocks that we created in the first world has been smoothed away. Sometimes this is desirable… but typically not.

So. Let’s take a look at the new version:

New Thermal Weathering

Hopefully you can see why I’m quite excited and proud of the new device. 🙂

Convincing talus slopes have been generated under the cliff faces. These slopes have a consistent (and controllable) angle of repose, as much volume as you want, and best of all not only preserve but even enhance the original erosion detail present.

The new device works great with or without traditional erosion. It’s also much more controllable than the old device (which was often a bit tweaky), has controllable mask inputs for both talus generation and talus sinks (where things like rivers can remove the talus), and, by the way, scales dramatically better than the old device in high resolution worlds — you’ll find some huge build time improvements.

In short, for most general purpose work, this device represents a giant leap forward, and finally deserves to be used on an equal basis with the regular erosion model. I’m excited that it’s now available, and look forward to hearing if you find it useful!